[PATCH] D129951: adds `__disable_adl` attribute

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a subscriber: lewissbaker.
cor3ntin added a comment.

In D129951#4179596 <https://reviews.llvm.org/D129951#4179596>, @cjdb wrote:

> In D129951#4179481 <https://reviews.llvm.org/D129951#4179481>, @ldionne wrote:
>
>> In D129951#4179467 <https://reviews.llvm.org/D129951#4179467>, @cjdb wrote:
>>
>>> I'm deeply disappointed that libc++ moved away from using `__function_like`: that was an important part of preventing niebloid misuse. It isn't conforming to treat niebloids as function objects, which is what `__function_like` prevented (I just checked `std::ranges::next` and it seems that `__function_like` was completely removed).
>>
>> Oops, it seems like my reply got into a race condition with yours. I am curious though, why is it non-conforming to treat niebloids as function objects? It is certainly more lax than required by the Standard, however we are allowed to make those copyable, aren't we? Does the Standard say that we *have* to make them non-usable as objects? That would change things for sure (not with this patch, but we'd probably want to try re-introducing `__function_like`, and we'd file a bug report against libstdc++ to do the same).
>
> "isn't conforming" is a bit too harsh in retrospect (this applies to //every// conversation I've brought this up in, although I meant that it allows users to write "non-conforming code"). A more accurate way to put this is: it is conforming on a per-implementation basis, but is //non-portable// due to namespace.std/p6 <http://eel.is/c++draft/library#namespace.std-6>. For example, a user who wants to use Microsoft/STL won't ever be able to take advantage of using `std::ranges::next` as a higher-order function (and could potentially have migration issues if they're porting to Windows), because their niebloids <https://github.com/microsoft/STL/blob/main/stl/inc/xutility#L3228> are derived from _Not_quite_object <https://github.com/microsoft/STL/blob/main/stl/inc/xutility#L3045-L3049>. `_Not_quite_object`'s predecessor in cmcstl2 was the inspiration for `__function_like`.
>
> As for a refresher on why this is the reason, it's because the functions in `std::ranges` //should// be functions, but we lack the technology to make them functions.
>
> In D129951#4179474 <https://reviews.llvm.org/D129951#4179474>, @ldionne wrote:
>
>> This is a really neat attribute! FWIW, I think we would most likely have used it in `<ranges>` if it were available back then. Assuming that GCC implemented it, I think we could consider changing to use this attribute. However:
>
> Thanks, glad you like it :-)
> (I think the "however" bit got addressed above.)
>
>> FWIW, my main thought is that I would like to see this proposed as a WG21 proposal. This might end up an attribute or something else, I'm not sure. But it would address the issue of not all implementations providing the functionality. IMO this patch and the data gathered in it would be a great motivation for WG21 to do something (I also know there are other proposals in this domain).
>
> I don't attend WG21 anymore, but could probably work with someone who is motivated enough to see it from Evolution through plenary. My preference is a specifier, rather than an attribute. For better, or for worse, most attributes are ignorable; this is certainly a property that should never be ignored.

@lewissbaker is the person you want to chat with!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129951