Add support for native-sized integers#1060
Add support for native-sized integers#1060RexJaeschke wants to merge 21 commits intodotnet:draft-v9from
Conversation
standard/expressions.md
Outdated
| ``` | ||
|
|
||
| A constant expression shall either have the value `null` or one of the following types: | ||
| 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`. |
There was a problem hiding this comment.
"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.
There was a problem hiding this comment.
I agree with @KalleOlaviNiemitalo, I'll offer the following – feel free to wordsmith:
| 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. |
| public override bool Equals(object obj); | ||
| public override int GetHashCode(); | ||
| public override string ToString(); | ||
| public string ToString(string format); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 .
| ### 8.3.1 General | ||
|
|
||
| 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. | ||
| 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. |
There was a problem hiding this comment.
§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.
There was a problem hiding this comment.
@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(ornuint) appears in the context of a value_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?
There was a problem hiding this comment.
Does the term "declared type" include type parameters?
class C<uint> {
void M(uint p) {}
}There was a problem hiding this comment.
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
nintandnuintare 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).
|
|
||
| The compile-time evaluation of constant expressions uses the same rules as run-time evaluation of non-constant expressions, except that where run-time evaluation would have thrown an exception, compile-time evaluation causes a compile-time error to occur. | ||
|
|
||
| Due to the implementation-defined nature of native integers ([§8.3.6](types.md#836-integral-types)), constant folding operations on `nint` and `nuint` operands shall be evaluated as if they had type `System.Int32` and `System.UInt32`, respectively. If the operation results in a constant value representable in 32 bits, constant folding may be performed at compile-time. Otherwise, the operation is executed at runtime and is not considered to be a constant. |
There was a problem hiding this comment.
“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
nintasSystem.Int32;- treat all values of type
nuintasSystem.UInt32;- and otherwise use the same evaluation rules as for run-time non-constant expressions.
If any
nint/nuintvalues 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 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.
| ``` | ||
|
|
||
| In a pointer element access of the form `P[E]`, `P` shall be an expression of a pointer type other than `void*`, and `E` shall be an expression that can be implicitly converted to `int`, `uint`, `long`, or `ulong`. | ||
| In a pointer element access of the form `P[E]`, `P` shall be an expression of a pointer type other than `void*`, and `E` shall be an expression that can be implicitly converted to `int`, `uint`, `nint`, `nuint`, `long`, or `ulong`. |
There was a problem hiding this comment.
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?
Co-authored-by: Kalle Olavi Niemitalo <kon@iki.fi>
Co-authored-by: Kalle Olavi Niemitalo <kon@iki.fi>
BillWagner
force-pushed
the
Add-support-for-native-sized-integers
branch
from
271e038 to
a35cd0d
Compare
|
Closed in favor of #1457 |
- #1060 (comment): Take Nigel's suggestion, with minor wordsmithing. - #1060 (comment) No change in this PR. Addressed with Rex's work on Annex C. - For #1060 (comment): Use Nigel's suggestion. - For #1060 (comment): Took Nigel's suggestion. - #1060 (comment) No change. Deferred to when we address #729
- #1060 (comment): Take Nigel's suggestion, with minor wordsmithing. - #1060 (comment) No change in this PR. Addressed with Rex's work on Annex C. - For #1060 (comment): Use Nigel's suggestion. - For #1060 (comment): Took Nigel's suggestion. - #1060 (comment) No change. Deferred to when we address #729
- #1060 (comment): Take Nigel's suggestion, with minor wordsmithing. - #1060 (comment) No change in this PR. Addressed with Rex's work on Annex C. - For #1060 (comment): Use Nigel's suggestion. - For #1060 (comment): Took Nigel's suggestion. - #1060 (comment) No change. Deferred to when we address #729
4 participants
IMPORTANT: There are two related MS proposals for native integer support: V9’s Native-sized integers and V11’s Numeric IntPtr.
V9 introduces
nintandnunintas two new types, which while required to map directly toSystem.IntPtrandSystem.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
nintandnuintfit 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!