19.2 Enum base type

[gafter]

An enum base type may be an integral type's keyword or any type name that resolves to one of the integral types.

The current text of the spec requires that it be the fully qualified name, but that's not actually what is implemented in C# 6. It could use an alias or an imported type name.

[RexJaeschke]

During the Nov 17 TG2 call, @jskeet noticed that admin/v6-feature-tracker.md did not seem to reflect the current status of that topic, and he asked me to investigate. Here are my findings:

15.5.4 Volatile fields

This currently contains the following:

These restrictions ensure that all threads will observe volatile writes performed by any other thread in the order in which they were performed. A conforming implementation is not required to provide a single total ordering of volatile writes as seen from all threads of execution. The type of a volatile field shall be one of the following:

• …
• An enum_type having an enum_base type of byte, sbyte, short, ushort, int, or uint.

Unless I'm reading it too literally, this constraint does not allow the System.* alias names for these keywords. Nor does it disallow the System.* alias names for long and ulong. I propose changing this constraint to the following:

• An enum_type having an enum_base type other than long, ulong, and their corresponding System.* aliases.

19.2 Enum declarations

As a result of PR #351, we have the following:

enum_base
    : ':' integral_type
    | ':' integral_type_name
    ;
integral_type_name
    : type_name // restricted to one of System.{SByte,Byte,Int16,UInt16,Int32,UInt32,Int64,UInt64}
    ;

Each enum type has a corresponding integral type called the underlying type of the enum type. This underlying type shall be able to represent all the enumerator values defined in the enumeration. If the enum_base is present, it explicitly declares the underlying type. The underlying type shall be one of the integral types (§9.3.6) other than char; specified either by keyword (integral_type), or by one of the full type names that the integral types alias (§9.3.5) (integral_type_name).

Note: Neither char nor System.Char can be used as an underlying type. end note

This looks right to me. However, if we want to express this entirely in the grammar, without textual constraints (which I am not necessarily advocating we do), we could use the following instead:

enum_base
    : ':' enum_base_type
    ;
enum_base_type
    : 'sbyte'
    | 'byte'
    | 'short'
    | 'ushort'
    | 'int'
    | 'uint'
    | 'long'
    | 'ulong'
    | 'System.SByte'
    | 'System.Byte'
    | 'System.Int16'
    | 'System.UInt16'
    | 'System.Int32'
    | 'System.UInt32'
    | 'System.Int64'
    | 'System.UInt64'
    ;

@gafter Have your concerns been addressed by Nigel's PR?

@Nigel-Ecma An ANTLR question: If we use the grammar-only approach, that means we'll have duplicate terminals (as in sbyte, byte, ...), which are already present in the keyword rule. Recall that I introduced the following named lexical tokens to avoid that for other terminals:

DEFAULT  : 'default' ;
NULL     : 'null' ;
TRUE     : 'true' ;
FALSE    : 'false' ;
ASTERISK : '*' ;
SLASH    : '/' ;

which suggests we'd need 8 more for these duplicate type names.

[Nigel-Ecma]

TL;DR: We don’t do the “spelled out” version for reasons ;-) The issue with the long “spelled out” option is the recognising System.* two ways. Such constructs are recognised as multiple terminals (Identifiers and the dot) which combined are matched by a chain of rules (lexical and parser) which end up at type_name. Recognising them contextually as a single token as well is not a (realistic) option. Note that the restriction in the comment can be implemented by ANTLR using its predicates should an implementor so choose. Cheers, Nigel

…

On 26/11/2021, at 7:04 am, Rex Jaeschke ***@***.***> wrote: 19.2 Enum declarations As a result of PR #351 <#351>, we have the following: enum_base : ':' integral_type | ':' integral_type_name ; integral_type_name : type_name // restricted to one of System.{SByte,Byte,Int16,UInt16,Int32,UInt32,Int64,UInt64} ; Each enum type has a corresponding integral type called the underlying type of the enum type. This underlying type shall be able to represent all the enumerator values defined in the enumeration. If the enum_base is present, it explicitly declares the underlying type. The underlying type shall be one of the integral types (§9.3.6 <x-msg://1/types.md#936-integral-types>) other than char; specified either by keyword (integral_type), or by one of the full type names that the integral types alias (§9.3.5 <x-msg://1/types.md#935-simple-types>) (integral_type_name). Note: Neither char nor System.Char can be used as an underlying type. end note This looks right to me. However, if we want to express this entirely in the grammar, without textual constraints (which I am not necessarily advocating we do), we could use the following instead: enum_base : ':' enum_base_type ; enum_base_type : 'sbyte' | 'byte' | 'short' | 'ushort' | 'int' | 'uint' | 'long' | 'ulong' | 'System.SByte' | 'System.Byte' | 'System.Int16' | 'System.UInt16' | 'System.Int32' | 'System.UInt32' | 'System.Int64' | 'System.UInt64' ; @gafter <https://github.com/gafter> Have your concerns been addressed by Nigel's PR? @Nigel-Ecma <https://github.com/Nigel-Ecma> An ANTLR question: If we use the grammar-only approach, that means we'll have duplicate terminals (as in sbyte, byte, ...), which are already present in the keyword rule. Recall that I introduced the following named lexical tokens to avoid that for other terminals: DEFAULT : 'default' ; NULL : 'null' ; TRUE : 'true' ; FALSE : 'false' ; ASTERISK : '*' ; SLASH : '/' ; which suggests we'd need 8 more for these duplicate type names.

[jskeet]

I was mostly reflecting that draft-v6 doesn't include some of the changes made in our previous repo, to be honest. There was a PR merged there that doesn't appear to have been merged here. I can try to find the details again, but it won't be before Monday.

[jskeet]

Closing in favour of #412.