[PATCH] D100668: [ADT] Add STLShims.h and llvm::disjunction

Scott Linder via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 16 14:25:12 PDT 2021


scott.linder added a comment.

In D100668#2695927 <https://reviews.llvm.org/D100668#2695927>, @dblaikie wrote:

> I don't think "shim" is the right term here - if anything I'd think things like our range-based adapters to standard algorithms (llvm::sort(R, C) -> std::sort(R.begin(), R.end(), C)) is a "shim" in the sense of the word that I know of - a thin adapter ( https://en.wikipedia.org/wiki/Shim_(computing) - "a shim is a library that transparently intercepts API calls and changes the arguments passed, handles the operation itself or redirects the operation elsewhere.").
>
> These are STL reimplementations, though that's a bit of a mouthful. STLCompat.h, perhaps?

Sure, I'm amenable to other names. I originally planned to use "polyfill" (https://en.wikipedia.org/wiki/Polyfill_(programming)) but landed on shim because:

- It is shorter
- It is an older term (I hoped more people would understand the use in this context)
- The term "polyfill" seems to almost universally apply to javascript (see e.g. http://speakingjs.com/es5/ch30.html#shim_vs_polyfill)

The definition of "shim" I was going for is the one from that speakingjs book: "A shim is a library that brings a new API to an older environment, using only the means of that environment."

I don't like just "reimplementation", even though it is accurate, because it doesn't really convey the intent; we will be deleting our version ASAP. We really don't care about the implementation per-se, we just want to code to a future specification. If we were dissatisfied with the standard implementations then "reimplementation" would seem more apt.

I also feel like just "Compat" is a bit ambiguous, but maybe I just think of "backwards" compat first. What do you think about STLForwardCompat.h ? That also brings up the questionof what happens when someone compiles LLVM with a newer standard than C++14, i.e. is this really "compatible" with the newer standards if we don't detect whether they are present? I am not sure how best to approach doing that in general.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D100668/new/

https://reviews.llvm.org/D100668



More information about the llvm-commits mailing list