INumber<TSelf> shouldn't inherit IUnaryNegationOperators<TSelf, TSelf>.

[JustNrik]

Description

I was fiddling around with the new INumber<TSelf> interface, but I found something that is definitely out-of-place.

INumber<TSelf> inherits IUnaryNegationOperators<TSelf, TSelf> which makes you implement this operator:

static abstract TSelf operator -(TSelf value);

At first sight it looks completely fine, but this is actually NOT fine for unsigned numbers. There's a really valid reason why uint returns long when you use the unary minus operator on it, or why ushort and byte returns int. And for this same reason, this interface shouldn't be part of INumber<TSelf> interface.

Suggestion

Move IUnaryNegationOperators<TSelf, TSelf> from INumber<TSelf> to ISignedNumber<TSelf>

In this way, IUnsignedNumber<TSelf> won't inherit such interface just to return a wrong data type or throw an exception.

Drawbacks

Breaking change but we are in previews so we're still in time, I personally consider it very necessary until its too late.
Another drawback is that now you have to implement IUnaryNegationOperators<TSelf, TResult> if you implement IUnsignedNumber<TSelf>, but that's how it should be.

Tagging subscribers to this area: @eiriktsarpalis
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I was fiddling around with the new INumber<TSelf> interface, but I found something that is definitely out-of-place.

INumber<TSelf> inherits IUnaryNegationOperators<TSelf, TSelf> which makes you implement this operator:

static abstract TSelf operator -(TSelf value);

At first sight it looks completely fine, but this is actually NOT fine for unsigned numbers. There's a really valid reason why uint returns long when you use the unary minus operator on it, or why ushort and byte returns int. And for this same reason, this interface shouldn't be part of INumber<TSelf> interface.

Suggestion

Move IUnaryNegationOperators<TSelf, TSelf> from INumber<TSelf> to ISignedNumber<TSelf>

In this way, IUnsignedNumber<TSelf> won't inherit such interface just to return a wrong data type or throw an exception.

Drawbacks

Breaking change but we are in previews so we're still in time, I personally consider it very necessary until its too late.
Another drawback is that now you have to implement IUnaryNegationOperators<TSelf, TResult> if you implement IUnsignedNumber<TSelf>, but that's how it should be.

Author:	JustNrik
Assignees:	-
Labels:	area-System.Linq, untriaged
Milestone:	-

[mairaw]

@tannergooding it seems this would be something for you. Not sure if the bot is right here 😉

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I was fiddling around with the new INumber<TSelf> interface, but I found something that is definitely out-of-place.

INumber<TSelf> inherits IUnaryNegationOperators<TSelf, TSelf> which makes you implement this operator:

static abstract TSelf operator -(TSelf value);

At first sight it looks completely fine, but this is actually NOT fine for unsigned numbers. There's a really valid reason why uint returns long when you use the unary minus operator on it, or why ushort and byte returns int. And for this same reason, this interface shouldn't be part of INumber<TSelf> interface.

Suggestion

Move IUnaryNegationOperators<TSelf, TSelf> from INumber<TSelf> to ISignedNumber<TSelf>

In this way, IUnsignedNumber<TSelf> won't inherit such interface just to return a wrong data type or throw an exception.

Drawbacks

Breaking change but we are in previews so we're still in time, I personally consider it very necessary until its too late.
Another drawback is that now you have to implement IUnaryNegationOperators<TSelf, TResult> if you implement IUnsignedNumber<TSelf>, but that's how it should be.

Author:	JustNrik
Assignees:	-
Labels:	area-System.Runtime, untriaged
Milestone:	-

[tannergooding]

When speaking more abstractly about numbers and how they are used by the hardware and even in higher level concepts like Vectors (particularly SIMD vectors), unary negation is a common operation supported by signed and unsigned types alike.It logically represents 0 - x.

Even for int = -byte and int = -ushort, this is logically 0 - x and then sign extended up to int. If you downcast back to byte, the actual bit-pattern remains the same. uint and ulong end up being "special" as the only primitive types that don't support unary negation in some fashion (and this is fairly specific to C#, not all languages).

It is exposed as there is logically little reason to force users into writing 0 - x to achieve what is ultimately the same result. There will be several other special considerations when dealing with INumber in addition to this, for example byte - byte = byte like you get in F#, and not byte - byte = int like you see in C#.