Add support for native-sized integers

[RexJaeschke]

IMPORTANT: There are two related MS proposals for native integer support: V9’s Native-sized integers and V11’s Numeric IntPtr.

• V9 introduces nint and nunint as two new types, which while required to map directly to System.IntPtr and System.UIntPtr, respectively, these new types are not synonyms for those underlying types. (They are, however, made synonyms in V11.)

• In V9 there are no predefined operators taking native integer types, and that instead implicit conversions are done to match the existing predefined operators. And that the predefined operators are added in V11.

The MS V11 spec appears to also include lots of edits that need to be applied to V9. For example, Rex took all the V11 conversion edits and put them in V9. And he ignored most stuff about operators in the MS V9 spec as it applies only to V11 (and the MS V11 spec reflects that).

Open Issue: It is likely that 12.6.4.7, "Better conversion target" is impacted by this feature addition; however, I was not able to determine how nint and nuint fit in there.

Open Issue: While researching this, I noticed that 12.4.7, “Numeric promotions” and its subsections are all marked as being informative. If so, where is this stuff stated/implied normatively? This would be OK if that content were stated (or implied) in some other, normative, place, but where is that? In any event, the supposedly informative text, “Binary numeric promotion consists of applying the following rules, in the order they appear here:” sure sounds normative to me!

[KalleOlaviNiemitalo]

The conversion from int to nint is already allowed in 10.2.3 Implicit numeric conversions; the int value is always within the range of nint. I don't think the conversion from int to nint should be mentioned here in 10.2.11 Implicit constant expression conversions.

[KalleOlaviNiemitalo]

"that type shall be […] a default value expression" doesn't make sense to me; a type is not an expression.

The value of a default value expression for a reference type is null anyway so I don't think default value expressions need to be explicitly mentioned here. OTOH this oddity is already there before this pull request.

[Nigel-Ecma]

I agree with @KalleOlaviNiemitalo, I'll offer the following – feel free to wordsmith:

Suggested change

	A constant expression may be either a value type or a reference type. If a constant expression has a value type, that type shall be one of the following: `sbyte`, `byte`, `short`, `ushort`, `int`, `uint`, `nint`, `nuint`, `long`, `ulong`, `char`, `float`, `double`, `decimal`, `bool,` or any enumeration type. If a constant expression has a reference type, that type shall be `string`, a default value expression ([§12.8.21](expressions.md#12821-default-value-expressions)) for some reference type, or the value of the expression shall be `null`.
	A constant expression may be either a value type or a reference type. If a constant expression has a value type, that type shall be one of the following: `sbyte`, `byte`, `short`, `ushort`, `int`, `uint`, `nint`, `nuint`, `long`, `ulong`, `char`, `float`, `double`, `decimal`, `bool,` or any enumeration type. If a constant expression has a reference type, the expression shall:
	- have a value of type `string`;
	- have a value of `null`; or
	- be a default value expression ([§12.8.21](expressions.md#12821-default-value-expressions)) of reference type.

[KalleOlaviNiemitalo]

System.IntPtr and System.UIntPtr are declared in §C.3 Standard Library Types not defined in ISO/IEC 23271, but they do not have ToString(string) methods there.

[RexJaeschke]

Thanks, @KalleOlaviNiemitalo. I'm rethinking this listing of included/excluded members (which I took from the MS spec). §C.2 has declarations for IntPtr and UIntPtr with no members shown. Even though the CLI spec does have members for each, none of those are required by Standard C, so we've omitted them until now. As such, it seems that I should remove the discussion and list of members that are explicitly excluded, as we've never acknowledged their existence previously, and there seems to be no good reason to do so now. (Or is there? See below.)

As for the implicitly included list, if we retain that as proposed, that would require adding those 4 members to C.2 (they are defined in the CLI). If we do that, the 2 methods having parameters need to have a ? suffix added to those parameters .

[KalleOlaviNiemitalo]

§6.4.4 Keywords says

A contextual keyword is an identifier-like sequence of characters that has special meaning in certain contexts, but is not reserved, and can be used as an identifier outside of those contexts as well as when prefaced by the @ character.

but this PR does not specify those "certain contexts" in which nint and nuint have special meaning.

[RexJaeschke]

@KalleOlaviNiemitalo. The grammar rule value_type now allows nint and nuint as alternatives, which gives all the situations in which these identifiers might have special meaning. But not every such use of these identifiers designates those type names. For example,

class nint { }
class Test
{
    static void M()
    {
        nint i = default;
    }
}

How about I extend line 154 above with the following?

A value type is either a struct type or an enumeration type. C# provides a set of predefined struct types called the simple types. The simple types are identified through keywords and contextual keywords. If the identifier nint (or nuint) appears in the context of a value_type and a declared type called nint (or nuint) is in scope, the declared name takes precedence over the use of the identifier as a contextual keyword.

Does that address your concern?

[KalleOlaviNiemitalo]

Does the term "declared type" include type parameters?

class C<uint> {
    void M(uint p) {}
}

[Nigel-Ecma]

The pattern used elsewhere in the Standard is to include a paragraph after the introduction of the grammar rule, value_type in this case, which states how the ambiguity is to be resolved. So at line 220 the following para can be inserted:

Because the names nint and nuint are not keywords there is syntactic ambiguity between recognising them as a type_name or a value_type. In context if type resolution (§7.8.1) on either of these names succeeds then that name shall be recognised as a type_name; otherwise it shall be recognised as a value_type.

This para follows the pattern used elsewhere, e.g. for notnull(§15.2.5).

[Nigel-Ecma]

“Constant folding” is an implementation optimisation term, it is in the source material only as it is describing the semantics by way of describing one particular implementation.

The semantics that need to be specified are that within a constant expression operations on native ints shall be evaluated as operations on 32-bit ints and if this conversion or runtime evaluation of the expression would have resulted in an exception then the expression is not a constant expression and a compile-time error shall be issued.

I'll offer as a starting point the following replacement for lines 6809-11:

The compile-time evaluation of a constant_expression shall:

• treat all values of type nint as System.Int32;
• treat all values of type nuint as System.UInt32;
• and otherwise use the same evaluation rules as for run-time non-constant expressions.

If any nint/nuint values are not representable as Int32/UInt32, or the run-time evaluation of the whole expression would throw an exception, then a compile-time error shall be produced.

Note: These rules mean that an expression involving native integers which is superficially valid as a constant_expression may only be valid as an expression evaluated at runtime using the full implementation-defined native integer precision. end note

I think this captures the semantics.

[KalleOlaviNiemitalo]

This reminds me about #729, where P[E] is used and the compile-time type of E is dynamic. Will the runtime binder now have to consider a dynamic conversion to nint, too?