On 11/20/2022 8:25 AM, IchorDev wrote:
> If you're sure that arithmetic and ETI won't mix for implementation reasons then I could explicitly prohibit it. My only apprehension is that `OR`ing enum flags with ETI is very handy.

It is handy and used a lot.

On 11/20/2022 1:47 PM, Adam D Ruppe wrote:
> On Sunday, 20 November 2022 at 21:32:16 UTC, Walter Bright wrote:
>> Nobody has complained about it shadowing.
> 
> Look at the yellow box a few paragraphs down here:
> 
> http://dpldocs.info/this-week-in-d/Blog.Posted_2021_02_15.html#tip-of-the-week

I did those classes because at the time it seemed that our target was Java developers. This has since proved to be incorrect, and I wouldn't do them again. But they don't seem to be any harm.

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
> }
> ```
> 
> Too messy for me, but up to you.

I'm not seeing where the shadowing is?

On 22/11/2022 1:46 PM, Walter Bright wrote:
> I did those classes because at the time it seemed that our target was Java developers. This has since proved to be incorrect, and I wouldn't do them again. But they don't seem to be any harm.

As someone who did in fact come from Java prior to D, I can say I have in the past appreciated they existed even if I didn't use them much.

Now if only we could do the same with structs ala Voldemort types...

On Tuesday, 22 November 2022 at 00:46:40 UTC, Walter Bright wrote:
> I did those classes because at the time it seemed that our target was Java developers. This has since proved to be incorrect, and I wouldn't do them again. But they don't seem to be any harm.

Oh they're really nice and I use them a lot.

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!)

On 22.11.22 01:41, Walter Bright wrote:
> On 11/20/2022 2:03 AM, Timon Gehr wrote:
>> To some extent I think this is the case, but function literals already defer the semantic pass in some way, so it seems feasible.
> 
> True, and templates also make a copy of the AST before instantiating it. But:
> 
> 1. template compilation is not known for speed or low memory consumption
> 
> 2. every function argument would have to be copied first, as it wouldn't know about $ processing in advance (or have to make a pass over it first to detect it)
> ...

I guess the two-pass thing is how function literals work, so you'd do that?

> 3. if there were, say, 5 occurrences of $a, each of that which could be 2 different instances to try, what's that, 32 copies
> 
> I'm not too thrilled about this.

The DIP does not propose trying all combinations. You'd get number of function overloads copies for each occurrence of $a. It's not exponential and without overloading (I think this is the majority of cases in typical user code) it is one copy.

On 22.11.22 01:42, Walter Bright wrote:
> On 11/20/2022 8:25 AM, IchorDev wrote:
>> If you're sure that arithmetic and ETI won't mix for implementation reasons then I could explicitly prohibit it. My only apprehension is that `OR`ing enum flags with ETI is very handy.
> 
> It is handy and used a lot.

The way D does it, it also has some issues:

enum E{
    a=1,
    b=2,
}

void main(){
    import std.stdio;
    writeln(E.a|E.b); // cast(E)3
}

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.

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.

The implementation of to!string for enums has some code like this:


switch(e){
    foreach(member; EnumMembers!E){
        case member:
            ...
    }
}

https://github.com/dlang/phobos/blob/master/std/conv.d#L1065-L1070

This is where the shadowing happens. You then get an compile error in the guts of Phobos.

(I originally thought writeln would break due to that issue, but it's not using the same code:
https://github.com/dlang/phobos/blob/master/std/format/internal/write.d#L3023-L3025

I am not fully sure if this will break with implicit with, but I think the DIP would allow $val here if the enum has a "val" member. So if you want to cover an equal amount of ground to the DIP, this will actually break too.)

I think spilling the implementation details of library code into user code like that is a no-go.

On 21.11.22 21:12, Guillaume Piolat wrote:
> On Monday, 21 November 2022 at 16:23:51 UTC, IchorDev wrote:
>> If you'd like to vote about what ETI syntax you'd prefer, I've opened a poll to keep track of how many people like which syntax.
>> The options I've listed are limited to ones that don't break compatibility with existing code. If you'd like an option added, let me know.
>> https://strawpoll.com/polls/PKglzqaGJyp
> 
> There is no .member syntax in your poll (which implies deprecating existing one)

_.member is also missing.