The conversion fromint tonint is already allowed in 10.2.3 Implicit numeric conversions; theint value is always within the range ofnint. I don't think the conversion fromint tonint should be mentioned here in 10.2.11 Implicit constant expression conversions.

"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 isnull 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.

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

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

Thanks,@KalleOlaviNiemitalo. I'm rethinking this listing of included/excluded members (which I took from the MS spec).§C.2 has declarations forIntPtr andUIntPtr withno members shown. Even though the CLI specdoes 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 (theyare defined in the CLI). If we do that, the 2 methods having parameters need to have a? suffix added to those parameters .

§6.4.4Keywords says

Acontextual 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 whichnint andnuint have special meaning.

@KalleOlaviNiemitalo. The grammar rulevalue_type now allowsnint andnuint as alternatives, which gives all the situations in which these identifiersmight have special meaning. But not every such use of these identifiers designates those type names. For example,

classnint{}classTest{staticvoidM(){ninti=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 thesimple types. The simple types are identified through keywords and contextual keywords.If the identifiernint (ornuint) appears in the context of avalue_type and a declared type callednint (ornuint) is in scope, the declared name takes precedence over the use of the identifier as a contextual keyword.

Does that address your concern?

Does the term "declared type" include type parameters?

classC<uint>{voidM(uintp){}}

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 namesnint andnuint are not keywords there is syntactic ambiguity between recognising them as atype_name or avalue_type. In context if type resolution (§7.8.1) on either of these names succeeds then that name shall be recognised as atype_name; otherwise it shall be recognised as avalue_type.

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

“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 aconstant_expression shall:

• treat all values of typenint asSystem.Int32;
• treat all values of typenuint asSystem.UInt32;
• and otherwise use the same evaluation rules as for run-time non-constant expressions.

If anynint/nuint values are not representable asInt32/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 aconstant_expression may only be valid as anexpression evaluated at runtime using the full implementation-defined native integer precision.end note

I think this captures the semantics.

This reminds me about#729, whereP[E] is used and the compile-time type ofE isdynamic. Will the runtime binder now have to consider a dynamic conversion tonint, too?