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

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D100668#2695979 <https://reviews.llvm.org/D100668#2695979>, @scott.linder wrote:

> 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)

Ah, yeah, that's not one I've come across personally.

> 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."

Yeah, it's certainly got some related use.

> 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.

ForwardCompat sounds OK to me, but given the other definition of shim, I'm probably OK-ish with that too.

Re: Newer standards. I think it's still compatible/doesn't make the name wrong if people are compiling in C++14 mode. But if we really wanted to, probably the closer we get to migrating to building with C++>14 by default, we might change these shims/whatever they are to be defined as aliases for the real implementations when compiling with a version that supports the implementation to help align things if they happen to be divergent in any way. Then eventually when the newer version is adopted as an LLVM requirement, we'd remove the fallback (so the llvm::* would only be an alias for the std:: version at that point) and then eventually remove the aliases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100668