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

[IchorDev]

On Tuesday, 22 November 2022 at 09:37:43 UTC, bauss wrote:
> If it's not implemented with .identifier then I will oppose it.
>
> I don't buy the "it will break code" point of view either.
>
> [...] if you type .a then it will first look in module scope, 
> then in enums that are in scope and at last within classes that 
> are in scope.
>
> I suggested something like it earlier too.
>
> Anything that is more complicated than .identifier is not worth 
> it and will only introduce unncessary complexity to the 
> language syntax.

`.identifier` has a multitude of issues, actually.
Doing this crazy "just ignore ETI if it coincides with module 
scope operator" idea was one I had before I wrote the DIP. It's 
clever, but it has a few major flaws.
1. Performance. Every time you try to use ETI, you're also 
triggering a module-scope lookup *every* time you compile your 
code. How would you know something like that without being told?
2. Intuitiveness. Nobody would understand this behaviour without 
a brief history lesson and a thorough explanation of how module 
vs. local vs. external variable lookup works. That might sound 
pretty simple to you, but to a new programmer that is a 
cluster-headache worth of information to take into account... 
just to use a shortcut.
3. Flexibility. Oops, did you just name a module-level variable 
"water"? Well, now you can't use ETI on the "water" member of 
your "Elements" enum! Why is that? Because we decided to try and 
fit two features into one operator. :)
4. Future expansion. Fitting *two* features into `.identifier` 
leaves type inference very little room for future expansion. 
Considering the other 3 issues, I think it would kill any 
possibility of type inference being added for other language 
features.

`$identifier` is less complicated, which is part of how it's most 
of the way through being implemented already.