[PATCH] D77056: [Sema] Allow non-member operators for sizeless SVE types

[Richard Sandiford via Phabricator via cfe-commits]

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