Description
There's only one thing holding back code such as the below from working right now, and it's that enums do not implement IBinaryInteger<self>:
static T ConsumeEnumValue<T>(ref ReadOnlySpan<byte> buffer, bool isUnsigned) where T : unmanaged, Enum, IBinaryInteger<T>
{
var value = T.ReadLittleEndian(buffer, isUnsigned);
unsafe { buffer = buffer[sizeof(T)..]; }
return value;
}Has automatic implementation of this interface this been considered, similar to how the runtime implements IReadOnlyList<T> on T[]? IBinaryInteger<T> for .NET enums seems like perfect fit. It would enable generic specialization without writing out a lot of manual reflection code to detect and handle each underlying int size separately. This would also enable enums to participate in all existing generic numerics code.
The compiler would have to detect the runtime capability similarly to how it detects whether the targeted runtime supports native integers. If the targeted runtime does not support it, then it would be a compile error to use a concrete enum type as the type argument to a type parameter constrained : Enum, IBinaryInteger<T>.
It would probably not be desirable for an emitted enum type to explicitly implement this interface in general because the implementation would generally be exactly the same per underlying integer type, and that could be a lot of metadata repetition.
This would only apply to enums whose underlying type implements IBinaryInteger<T>.
Most of the implementation would simply be reusing the IBinaryInteger<T> implementation for the underlying integer type. The exceptions would be:
- Formatting and parsing to and from chars, which would unify with existing enum formatting and parsing logic.
- TryConvertTo/TryConvertFrom implementations would allow converting to and from the underlying integer type, so that
ulong.CreateTruncating(anyEnumValue)could work and vice versa.