cjdb added a comment. 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. 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
