[libcxx-commits] [PATCH] D104175: [libcxx][iwyu] ensures we IWYU as prep for modules

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb added inline comments.


================
Comment at: libcxx/include/__function_like.h:40
 
-  void operator&() const = delete;
-
----------------
Quuxplusone wrote:
> cjdb wrote:
> > ldionne wrote:
> > > Why is this change necessary?
> > The modules build seems to think that types derived from `__function_like` still have addresses. This sent me round the twist trying to figure out why, and I eventually explicitly deleted the operators in the derived types.
> > 
> > I don't want anyone to need to go through this again, so I think it's best we delete the operator from the base type so people realise they need to add it to the derived type.
> This explains the many changes in `__iterator/advance.h` etc.
> Since this is absolutely unrelated to IWYU, I think it should be a separate PR. Also, for the record, I'll repeat my usual drumbeat that libc++ //does not have to do any of this// `__function_like` stuff, and if it's causing problems, I'd prefer us to just rip it out so that the libc++ code will be as simple as possible.
> Since this is absolutely unrelated to IWYU, I think it should be a separate PR. 

Sure, I can move it into D104170 patch, since it's directly driven by that patch.

> This explains the many changes in `__iterator/advance.h` etc.
> Also, for the record, I'll repeat my usual drumbeat that libc++ //does not have to do any of this// `__function_like` stuff, and if it's causing problems, I'd prefer us to just rip it out so that the libc++ code will be as simple as possible.

It would be really beneficial if you bothered to understand design decisions instead of wrongly asserting that something isn't necessary ad infinitum.

I'll spell it out for you, even though it's documented directly above this type's definition. Everything derived from this type is supposed to have the properties of a function. Functions cannot be default constructed. Functions cannot be moved. Functions cannot be copied. Standard functions are not allowed to have their addresses taken. It's extremely tempting to use functions that are derived from `__function_like` as higher-order functions. [[ https://www.hyrumslaw.com/ | Hyrum's law ]] dictates that users will eventually treat this as allowed if we don't prevent these things from happening. There was a deliberate decision to not make them function objects in the standard, and I do not want users to start treating them as if they are.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104175