Please make sizeof(T) compatible with uint/nuint

[rickbrew]

I'm writing lots of interop code these days, and I constantly have to add all these casts for things like

someWin32Struct.cbSize = (uint)sizeof(SOME_WIN32_STRUCT);

And even the new NativeMemory requires me to do this because it takes a nuint,

this.pCriticalSection = (CRITICAL_SECTION*)NativeMemory.Alloc((nuint)sizeof(CRITICAL_SECTION));

sizeof() is a const expression that will never be negative, so I feel like the casting should really be unnecessary / implicit, like it is if I assign a non-negative const int to a uint.

I know @tannergooding and @Sergio0694 will back me up on this :)

[jnm2]

Please, yes. This is such a common stone in my shoe, more than ever now that https://github.com/microsoft/CsWin32 (the new official vehicle for Windows APIs) follows the metadata and generates every cbSize as uint.

[tannergooding]

Yep, I hit this regularly in my own code and its always frustrating that there isn't a general concept of "non negative signed integer".

.NET, throughout the entire ecosystem, takes in signed integers (int/Int32) but most methods do not allow or handle negative inputs and so if (value < 0) { throw ArgumentOutOfRangeException(); } exists at the top of many many methods (including indexers and the like). I therefore think it would be useful to be able to track that a given signed integer should only ever be positive (like nullable reference types tracks if a reference type can or cannot be null).

This would help avoid bugs and address correctness issues, like nullable reference types, but it could also allow better handling of things like:

• sizeof(T) can only return a positive value
• stackalloc, new T[], T[index], etc can only take positive values
• etc

It could also allow implicit conversion from non-negative signed integer to unsigned integer (still preferencing the original signed type in overload resolution cases).

[RikkiGibson]

This makes me think of the special behavior introduced for Length/Count property patterns. That is, with the list-patterns feature list is { Length: < 0 } is an error since our analysis is already assuming that Length will never be negative--so it's a pattern that will never match.

public class C {
    public void M(int[] x) {
        if (x is { Length: < 0 }) // error CS8518: An expression of type 'int[]' can never match the provided pattern.

        {
        }
    }
}

SharpLab

Maybe there is some natural/logical extension from this behavior that leads to what you're describing.

[RikkiGibson]

It seems like we could just define a constant value conversion the same way we do for integer literals.

[h3xds1nz]

Yeah, implicit conversion on sizeof would be an awesome and most welcome addition.

A lot of my interop codebases but also bunch of serialization classes that deals with uint as size (since negative doesn't make sense) is cluttered with these casts to (mostly) uint or nuint in case of size_t, which just reduces readibility and ergonomics.

[TahirAhmadov]

I'm curious if it's possible to ditch int for uint across .NET in a perfect world. Are there concerns with CPU not being able to handle "uint" operations as efficiently as "int" ones? Is it just legacy from previous languages/frameworks?

[TahirAhmadov]

Interesting.
The result of subtract uint from uint should definitely be of type int.
What do you mean by overflow?
I agree it's an impossibly large breaking change (hence "in a perfect world").
I'd like to find out more about the optimization pitfalls of uint, is there any info available to read? I don't want to ask you to spend time explaining all that.

[theunrepentantgeek]

The result of subtract uint from uint should definitely be of type int.

It can't be.

A unit can be as large as 4,294,967,295, an int can only be as large as 2,147,483,647.

If you take uint 4,000,000,000 and subtract uint 10, the correct answer will be 3,999,999,990.

If you bitsmash that into an int instead, you'll get -1,852,516,343 (assuming my math is correct), which is quite wrong.

This is what's meant by overflow.

Generally speaking, if you're subtracting two n-bit unsigned binary integers, you need n+1 bits in a signed result.
(I'm trying to remember if there's an edge case requiring n+2 bits; I don't think so, but those classes were a long time ago.)

[TahirAhmadov]

Oh OK, I see the issue, my thinking was it's much more common to subtract 10U - 20U, than to subtract 4_000_000_00U - 10U.

[tannergooding]

The result of subtract uint from uint should definitely be of type int.

This wouldn't be valid in many scenarios. Consider simply uint.MaxValue - 1 which cannot be represented as an int.

It is typical that if you have T in, you get T out. Overflow is then typically defined for integers via standard 2's complement behavior, which is that MaxValue + 1 wraps around to MinValue.

I'd like to find out more about the optimization pitfalls of uint, is there any info available to read? I don't want to ask you to spend time explaining all that.

Not sure if there's any good centralized resources. You'll find a lot of conflicting information because there are many optimizations that people say apply to unsigned types when in actuality they mean it applies to positive numbers instead. Which is to say, there is no difference between a uint and an int which is known to be constrained to [0, MaxValue] (because it cannot be negative).

A lot of the issues with unsigned types comes down to what happens during overflow. That is, when (x + y) > MaxValue or (x - y) < MinValue if the arithmetic was given infinite precision. There's also some considerations as it applies to certain range checks or similar.

This is namely an issue because any bit in the value represents a valid positive number. Where-as an int that is known "never negative" is known to never have its most significant bit set, and so that bit is able to serve as a type of flag to indicate overflow. The way 2's complement arithmetic works also means that any negative number T converted to the same sized unsigned type U will be greater than T.MaxValue, which allows things like (x < LowerPositiveLimit) || (x > UpperPositiveLimit) to become a single check. Likewise, addition of opposite signed values cannot overflow and subtraction of same signed values cannot overflow for signed types. So x - y where x and y are both known to be positive will at worst produce a negative number, allowing you to correctly compute differences and also utilize this to optimize various scenarios. Because you know that both inputs are positive, all the same optimizations that would've been valid for uint are also valid for a "never negative signed integer".

Knowing an int is never negative is pretty common, especially given argument validation. Knowing a uint is never greater than 0x7FFF_FFFF is a lot less common in contrast, as such a check isn't typical.

[TahirAhmadov]

Thank you, I appreciate the info.