On Sunday, 20 November 2022 at 18:03:04 UTC, H. S. Teoh wrote:
> On Sun, Nov 20, 2022 at 03:31:44AM +0000, ryuukk_ via Digitalmars-d wrote: [...]
>> ```D
>> MySuperDuperLongEnum stuff = MySuperDuperLongEnum.VALUE_A;
>> ```
>
> Why not just write:
>
> 	auto stuff = MySuperDuperLongEnum.VALUE_A;
>
> ?  No repetition necessary.

```D
struct Data
{
    MySuperDuperLongEnum flags;
}

Data data = {
    flags: .VALUE_A | .VALUE_B
};

```



> [...]
>> why should i use an alias here?
>> ```D
>> ctx.network_state = State.NetworkState.CONNECTED;
>> 
>> // vs
>> 
>> ctx.network_state = .CONNECTED;
>> ```
>
> Walter's proposal of implicit `with` would solve this case.
>
>
> T

Implicit is indeed a good idea, Adam's idea is also interesting

On 11/20/2022 8:25 AM, IchorDev wrote:
> On Saturday, 19 November 2022 at 04:14:18 UTC, Walter Bright wrote:
>> Is that a good thing? I'm not sure. This is also not addressed in the DIP.
> 
> Well `dra(E.e);` doesn't compile, so neither should `dra($e)` to my mind.

Ok, but that needs to be in the DIP!

On 11/20/2022 1:56 AM, Timon Gehr wrote:
> I have somewhat mixed feelings about implicit `with`. On one hand, it's even more convenient than `$e` `_.e`, `:e` etc, but on the other hand it's even less predictable for a user where it will work, and it can shadow variables from outer scopes (which is also a breaking change).

Consider that we already have implicit with for field access within non-static member functions. I.e. `a` instead of `this.a`. Nobody has complained about it shadowing.

But yes, it would be a (small) breaking change.

On 20.11.22 22:32, Walter Bright wrote:
> On 11/20/2022 1:56 AM, Timon Gehr wrote:
>> I have somewhat mixed feelings about implicit `with`. On one hand, it's even more convenient than `$e` `_.e`, `:e` etc, but on the other hand it's even less predictable for a user where it will work, and it can shadow variables from outer scopes (which is also a breaking change).
> 
> Consider that we already have implicit with for field access within non-static member functions. I.e. `a` instead of `this.a`. Nobody has complained about it shadowing.

It's in a nested scope, so that's more expected.

> 
> But yes, it would be a (small) breaking change.

Well, I'd be happy to retire some of my with statements.

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

>
> But yes, it would be a (small) breaking change.

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.

On 20.11.22 22:58, 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.

Actually, I think with the current implementation of writeln this will work (subject to break at any time), but not this:


```d
enum Role{
    guest,
    member,
    developer,
}

void main(){
    Role r;
    string s=to!string(r); // error
}
```

Not a big fan of making local variable names part of the public API.