Casting a negative literal value to nint or nuint requires parentheses

Take the following sample code:

public class C {
    uint x = unchecked((uint)-1);      // Ok
    uint y = unchecked((uint)(-1));    // Ok - Suggests removing unnecessary parentheses

    nuint z = unchecked((nuint)-1);    // CS0119 and CS0075
    nuint w = unchecked((nuint)(-1));  // Ok
}

https://sharplab.io/#v2:EYLgtghgzgLgpgJwDQxASwDYB8ACBmAAhwCYCBhAgbwFgAoAhggVzQDsYCAPAgXmdYDGACzgCA1nAAmACmkt2ASgC0ARgUBuRowD02ggHkxdLfI4BPXv2GiJMuWxgLpqhRq26DYgkoIBlJgDmAXCwUAQIcGAA9gBubAH8rKIhUBAIFgAOaXDsIlAhdMaMrKYEAF6WTIIi4lKyJQ7Kapo6emS+AAwqKgCcBBCskuSdHQDsAKxFDA3sBADuldU2ddIzjs5qbgQehnQAvkA

I would expect nuint (and nint) to also allow casting without surrounding the negative integer literal with parentheses.

[alrz]

Because parser doesn’t know if type is actually a type or expression at parse time, so that is parsed as a binary operator with a parenthesized lhs rather than a cast. I think that’s why CS0075 exists after all, as a hint when the identifier determined to be a type.

On the other hand, when a keyword is used, it is parsed as a cast from get-go – there’s no way uint could be an expression. Note this is not about primitive types themselves, (Int32)-1 has the same ambiguity and yields an error. It must be a keyword.

If the cast operator had a higher precedence than a parenthesized expression (which in turn, defined under “primary expressions”), it could work but that is just not how the grammar is specified. If possible at all, it would have need a lot of lookaheads and does not simply fit into other production rules.

[cston]

Thanks @alrz for the detailed explanation.

nint and nuint are identifiers rather than keywords so the current behavior is expected.

Closing as “by design”.