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

bauss jacobbauss at gmail.com
Fri Nov 25 06:30:45 UTC 2022


On Thursday, 24 November 2022 at 14:36:26 UTC, IchorDev wrote:
> 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.

$identifier is ugly IMHO and anything that requires any new 
operators is just not worth it.

As I stated before then I am against this DIP.

The feature isn't that important that I want code to be cluttered 
with new syntax that hardly adds anything.


More information about the Digitalmars-d mailing list