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.
>
> 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.
>
> 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.
>
> Example:
>
> ```d
> class A { static int a = 1; static int b = 2; }
> enum B { b = 3, c = 4 }
> int c = 5;
>
> void main() {
>   writeln(.a);
>   writeln(.b);
>   writeln(.c);
> }
> ```
>
> Prints:
>
> 1
> 3
> 5

I agree with this. In general the D project has become "don't break my beautiful parser/lexer" rather than what languages are supposed to do which is helping humans create/read code.

Another thing is that globals are in general sparse so that there will likely not be an ambiguity between enums and globals. There is a higher likely hood that there will be a ambiguity between locals/members and enums with the syntax without the '.'.

The . syntax is used in several other languages which helps and also it also helps the programmer understanding that it is an enum and not variable of any kind.

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.

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:

>> 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.

Maybe somebody could scan some github repos and find out how often there's an enum member name that clashes with something in module scope? Would that be hard to do?

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".

On 11/21/2022 5:22 PM, Timon Gehr wrote:
> Some other languages require some annotation on the enum to indicate that it is to be used as flags and disallow arithmetic otherwise, writeln could pick that up also and format it nicely as a|b.

It's not perfect, but at some point adding more complexity to try to fix it becomes a larger problem.

On 11/21/2022 4:59 PM, Adam D Ruppe wrote:
> But the variable shadowing due to the implicit `with(this)` can be quite a surprise, including some spooky action at a distance (adding something to the base class can erase a local variable from existence in an entirely different project!)

It's the old tradeoff problem. You can make the bathroom bigger or the closet bigger, but not both.

On 11/21/2022 5:41 PM, Timon Gehr wrote:
> On 22.11.22 01:49, Walter Bright wrote:
>> On 11/20/2022 1:58 PM, Timon Gehr wrote:
>>> On 20.11.22 22:32, Walter Bright wrote:
>>>>
>>>> But yes, it would be a (small) breaking change.
>>>
>>> I really wouldn't want to run into this:
>>>
>>> ```d
>>> enum Role{
>>>      guest,
>>>      member,
>>>      developer,
>>> }
>>>
>>> void main(){
>>>      Role r;
>>>      writeln(r); // error
> (Should perhaps be auto s = to!string(r);)
>>> }
>>> ```
>>>
>>> Too messy for me, but up to you.
>>
>> I'm not seeing where the shadowing is?
> 
> That's indeed basically the point. It's invisible.

This code:

---
import std.stdio;

enum Role{
     guest,
     member,
     developer,
}

void main(){
     Role r;
     writeln(r); // error
}
---

compiles successfully and when run prints:

guest

On Tuesday, 22 November 2022 at 18:13:00 UTC, Walter Bright wrote:
> It's the old tradeoff problem. You can make the bathroom bigger or the closet bigger, but not both.

my point is just your statement that nobody ever complained about implicit(this) is demonstrably false.

On Tuesday, 22 November 2022 at 18:16:43 UTC, Walter Bright wrote:
> compiles successfully and when run prints:

Did you implement the implicit with?

The point is that proposal will introduce a regression with that code.