[PATCH] D99561: Support visitor pattern by PointerUnion.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 6 15:56:45 PDT 2021


dblaikie added a comment.

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

> To chime in on the spelling of things relative to `std`, I had similar questions for IntrusiveVariant in https://reviews.llvm.org/D98477
>
> A natural question that might help with deciding how to handle `visit` is: how should we spell alternative type access? `std` uses the free function `std::get`. It makes sense, as that same free function is overloaded for e.g. `std::tuple`, `std::pair`, `std::variant`, etc. but we don't currently have anything similar in ADT.
>
> I think my leaning would be to go all-in on the `std` approach by doing the following:
>
> - Add an `llvm::adt` namespace (or something similar) containing things which are "designed to fulfill the same roles as the identically-named member of the `std` namespace, but for whatever reason we cannot actually use that member directly". Generally the reason will be: that thing is not an extension point, and it is forbidden to re-open `std` to overload that thing.

Oh - what would happen if the name went in llvm directly and we called it via adl? ie: made the call unqualified & let ADL+overload resolution sort it out?

> - Add the appropriate `llvm::adt::get(llvm::PointerUnion)` overloads
> - When adding `InrusiveVariant`, I can add `llvm::adt::get(llvm::IntrusiveVariant)` overloads
> - Add `llvm::adt::visit` and the appropriate `llvm::PointerUnion` overloads
> - When adding `IntrusiveVariant`, I can add `llvm::adt::visit` overloads
>
> Then everything is spelled the same/quacks the same, but names are not ambiguous in the context of `using namespace llvm;` or `using namespace std;` or both.

Are there cases where they'd be ambiguous, though? Wouldn't template ordering still match them distinctly, unless one or more of these templates were overly general?

> For other things, where we expect to delete our copy entirely once we move the codebase to a certain `std` version, we can just drop the exact "polyfill" definition with the same name into `llvm::`, and then delete the code later. An example I plan to post a patch for is `in_place{_type,_index}_t`.
>
> What are people's thoughts?
>
> Edit: Alternatively the additional namespace I mention could be omitted, and every use of e.g. `get` would have to be qualified with either `std::` or `llvm::` if it would be ambiguous. My intention was to try to make it obvious that the `adt::` version is definitely not //actually // the `std::` version, even with the most common forms of `using namespace`.

I'm not sure to me it's important that they be obviously distinct - if they do the same thing I'm OK with it being a bit vague. Like 'swap' called via the adl (admittedly that one's very well documented as being adl) - overload resolution'll work itself out and if the behavior's obvious enough I don't think it'll matter to most folks whether it's implemented by the standard or llvm.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99561



More information about the llvm-commits mailing list