Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1

[XavierAP]

On Friday, 25 November 2022 at 19:40:35 UTC, Nick Treleaven wrote:
> On Tuesday, 22 November 2022 at 04:17:37 UTC, IchorDev wrote:
>> On Tuesday, 22 November 2022 at 01:43:25 UTC, Timon Gehr wrote:
>>> _.member is also missing.
>>
>> `_.member` could break existing code, sorry. :(
>
> I think only if someone named a variable `_`. That does not 
> seem a sensible variable name to use and any breakage of that 
> is justified IMO. I know it's sometimes used as a function name 
> for translations - though because that requires an argument I 
> think that distinguishes it from possible use for ETI.
>
> The nice thing about this syntax (ironically) is it's already 
> an expression so:
>
> 1. it's more intuitive than using a new sigil. It looks like 
> accessing a member of something, which it is. Underscore is 
> often used in other languages to mean don't care, i.e. infer 
> the parent type. (In cppfront you can use underscore instead of 
> a function parameter type and the type will be inferred).
>
> 2. We aren't using up any syntax or reserving a sigil for this 
> feature so there's more syntax available for any future 
> features.

Right on.

But... Why then not not go one step further, and leave it up to 
each one's private code to

     alias _ = EType;

when desired, and leave the language and backwards compatibility 
alone?