rsandifo-arm added a comment. Thanks for the reviews.
In D77056#2463959 <https://reviews.llvm.org/D77056#2463959>, @rsmith wrote: > That said, I'm concerned that the design of this feature will severely limit > its utility. For classes and enums, operators are typically defined in an > associated namespace so that they can be found by ADL. For these types, there > are no associated namespaces, so user-defined operators for them can never be > found by ADL, and such operators are essentially never going to work in > generic code. Maybe that's not something you care too much about for the > intended use cases? Yeah, we don't expect the intended use cases would depend on ADL. The main aim is to support a style of SIMD framework in which all operations are performed using operators or using non-member functions. The SIMD framework would then have two choices: 1. If all those non-member functions belong to a namespace `foo` and if the SIMD framework expects users to be `using namespace foo`, the non-member operator overloads can simply be defined in `foo` and be brough into scope that way. 2. Otherwise, the framework could handle non-member operator overloads in one of the following ways: - define the overloads to be static (perhaps the least likely) - define the overloads in an anonymous namespace - define the overloads in an internal namespace and make the header file use that namespace at global scope The second choice would be awkward if a header file wanted to use the SIMD framework internally but leave the user free to use a different SIMD framework. That sort of use case would require the first choice instead. However, we expect in practice this feature will mostly be used in well-controlled environments where there is no risk of a clash between SIMD frameworks within a package. Requiring the overloads to be static or defined within a namespace is just to prevent accidental ODR violations between packages that are linked together. Either way, I realise this isn't great style. It just seems like a practical compromise between the rock of classes having a constant size and the hard place of vectors having a variable length. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77056/new/ https://reviews.llvm.org/D77056 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
