[cfe-dev] RFC: Allow non-member operator overloads for SVE types

[Richard Sandiford via cfe-dev]

TL;DR: This message is an RFC about allowing non-member operator
overloads to be defined for SVE types, much like enumerators.
The associated patch is https://reviews.llvm.org/D77056

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SVE types are defined to be opaque built-in types that by default
can only be used via intrinsics.  One consequence of this is that
the types provide no built-in versions of the unary and binary
arithmetic operators.

Instead, we'd like to allow users to define non-member operators
for SVE types, in much the same way as for enumeration types.
This specifically means:

* replacing "enumeration" in sections [over.match.oper] and [over.oper]
  with wording that includes both enumerations and SVE types.

* extending the enumeration handling of operator= in [over.built]
  to include SVE types.

An alternative would be to build the operators into the compiler.
However, we didn't want to do that for several reasons:

* Some of the operators would not be performance-portable.
  (E.g. %, and the 8-bit and 16-bit integer versions of /.)
  The SVE ACLE is supposed to be a low-level, almost asm-level
  interface to the architecture, so synthesising this kind of
  operation seems out-of-place.

* SVE types cannot be used in structures, so unlike with normal vector
  types, the user doesn't have the option of using a wrapper class to
  opt out of the standard handling.

* If in future we do want to provide a core group of operators in a
  standard header file/module, we could use this extension to write it.
  And if we still wanted to implement the bodies of the overloads directly
  in the compiler, we could use function attributes to achieve that.

Eli pointed out in the patch review that, unlike classes and enumerators,
these built-in types don't have an obvious owner, so there was a higher
risk of accidental ODR violations.  The current version of the patch
therefore follows Eli's suggestion of requiring the operators to be
defined in a namespace or as static functions, unless the operator
also has a class or enumerator argument.

Any thoughts?  Does this seem reasonable?

Thanks,
Richard