November 20
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

November 20

On Sunday, 20 November 2022 at 19:11:31 UTC, Johan wrote:

>

On Sunday, 20 November 2022 at 16:30:46 UTC, ryuukk_ wrote:

>

On Sunday, 20 November 2022 at 16:14:41 UTC, Johan wrote:

>

On Sunday, 20 November 2022 at 01:00:58 UTC, deadalnix wrote:

>

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":

https://github.com/dlang/DIPs/blob/e2ca557ab9d3e60305a37da0d5b58299e0a9de0e/DIPs/DIP1044.md

I have very simple feedback.

STOP CHANGING THE GOD DAMN SYNTAX!
STOP, STOP, STOP, and if you still have some doubt, STOP!

Every time, it breaks a ton of tools.

It's not worth it.

If typing the name of the enum is too long, then just use with or alias E = MyEnumNameThatIsTooLongAndAnoyingToType;.

These changes do not solve any actual problem. They just break tools.

I quite strongly agree.

The DIP does not show any real improvements. The rationale mentions "few drawbacks" but then does not mention those actual drawbacks, so people can judge whether they are few or not.

The DIP show this example as an improvement:

    myObj.myFn($medium, $square, $undefined);

Is the height medium?, the location the town square?, the shape undefined?
This is the "worse" version:

    myObj.myFn(Size.medium, Shape.square, State.undefined);

Code will be read much more often than it is written.
Please give a real world example where really the enum name is so long and tedious that reading it is worse than without (and where with does not solve the problem).

Besides tooling, also take into account someone relatively unfamiliar with D, stumbling upon a $. (now what the heck is this gratuitous obfuscation?)

-Johan

D has good type system

Irrelevant.

It is relevant, care to bring more argumentation?

> >

first off, name properly your functions/types/variables

Irrelevant.

It is relevant, care to bring more argumentation?

> >

then about the problem you are raising:

In your long email, you are not addressing at all how this DIP addresses any of the problems I am raising. Just mentioning more examples of code that are not fixed by this DIP.

I'm unfortunately not qualified to answer every concerns and questions, i'm not a language developer or a compiler designer, i never wrote grammar stuff, i'm a mere language user, i can only share my experience writing code in my project

So i am thankful for all of you who share your opinions too, there is lot to learn

> >

TOK enum in DMD codebase instead of SymbolTokenType

Thank you for this example. Search DMD codebase for TOK, and tell me how this DIP would matter for renaming TOK to SymbolTokenType:

dmd/compiler/src/dmd/cond.d:
  195      {
  196          auto tf = new TypeFunction(ParameterList(), null, LINK.default_, 0);
  197:         auto fd = new FuncLiteralDeclaration(loc, loc, tf, TOK.reserved, null);
  198          fd.fbody = s;
  199          auto fe = new FuncExp(loc, fd);
  ...
  407              auto exps = new Expressions(length);
  408
  409:             if (rangefe.op == TOK.foreach_)
  410              {
  411                  foreach (i; 0 .. length)
dmd/compiler/src/dmd/cparse.d:
  112          while (1)
  113          {
  114:             if (token.value == TOK.endOfFile)
  115              {
  116                  addDefines();   // convert #define's to Dsymbols

This DIP is not needed. TOK can happily be renamed to SymbolTokenType.
Let's not waste time on it.

-Johan

I used TOK example because it was mentioned in this thread

if (token.value == TOK.endOfFile)

what's token.value????? you guessed that .value is the value of the TokenType?

if (token.token_type == .endOfFile)

I'd love to know what was the reasoning behind TOK naming, was it because it was too long? that would be my guess

November 20
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!
November 20
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.
November 20
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.
November 20
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.


November 20
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.
November 20
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.
November 21

On Friday, 18 November 2022 at 15:37:31 UTC, Mike Parker wrote:

>

Discussion Thread

This is the discussion thread for the first round of Community Review of DIP 1044, "Enum Type Inference":

Not a fun of it using $identifier to imply inference.

I would much rather like .identifier.

I know that is currently used for module scope, but it could have been changed to something like static interference instead, so it will default to module scope, but can look into other types like enum, static members of classes etc.

Basically:

int a = 1;
class B {
  static:
  int b = 2;
}
enum MyEnum { c = 3 }
void main()
{
  writeln(.a);
  writeln(.b);
  writeln(.c);
}

Output:

1
2
3

Basically module scope has first priority, second enum, third static members.

So an ambiguity error shouldn't happen if a module scoped variable is named the same as an enum member etc.

November 21

On Monday, 21 November 2022 at 09:25:53 UTC, bauss wrote:

>

Not a fun of it using $identifier to imply inference.

Typo: Meant fan

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18