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

[bauss]

On Tuesday, 22 November 2022 at 12:27:41 UTC, claptrap wrote:
> On Tuesday, 22 November 2022 at 09:37:43 UTC, bauss wrote:
>> On Tuesday, 22 November 2022 at 05:55:04 UTC, rikki cattermole 
>> wrote:
>>> On 22/11/2022 6:47 PM, IchorDev wrote:
>>>> For instance, if everyone voted for "no syntax" then the 
>>>> poll would be useless to me.
>>>
>>> But it would tell you something useful.
>>>
>>> It would suggest a lot of people are wanting to explore 
>>> semantic behavior instead. Such as Walter's alternative 
>>> proposal idea.
>>
>> 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.
>>
>> The only thing I can think of that will break is that 
>> .identifier already has a meaning today that means module 
>> scope.
>>
>> But that could easily mean module AND "static/scoped" lookup 
>> and any ambiguity can be fixed by prioritization.
>>
>> 1. module scope 2. enum 3. static members of ex. classes
>>
>> So 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.
>
> Why not an error if it's ambiguous? There are ways to specify 
> which you want if needed. And its probably unlikely enough that 
> occasionally having to specify the enum name is not anything to 
> be concerned about.

An error with ambiguity is fine, BUT I think it shouldn't happen 
in the cases I provided, it should only happen in cases you have 
two symbols with same priority. So no error should be displayed 
if a global is named "a" and an enum member is named "a", BUT it 
should have an error if there are two enum members named "a", 
UNLESS there is also a global named "a".