Thank you, but there's a reason why unary - isn't defined for these types: it makes no sense to negate an integer that can only be positive.

Why do you need this? If you need to generically turn a number to be positive you can use abs.

Yeah, i understand why we can not create a negative unsigned int, but i am not mutating the value, i'm returning negative value of an unsigned int.
I'm having problems with generic class that receive an int type as parameter. When value is negative i do value = -value that obviously it can't occur when T is an unsigned type but it gives a compilation error.

You can use abs for this. This "trick" is used in many places in the standard library.

Yes, with abs it works properly, but, IMHO any class that inherits from Int or Number should support unnary -, this is an operation that can be applied to any number. Child classes should not constraint parent's operations.

The problem is that in your implementation the unary - returns a different type, which is totally unexpected. Basically:

var = ...
# Oops, now var is a union of two types, making everything slower
var = -var if some_condition

With abs you don't have that problem, and it works well, and in my use cases it covers every need (you basically do var.abs if var < 0).

We try to avoid this type-change in many places. I think it could also lead to unexpected bugs ("why did the compiler allow my to negate an unsigned integer, given that it has no sign?")

I'm closing this as we can continue discussing this but I won't change my mind.