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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
