www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIPX: Enum Literals / Implicit Selector Expression

reply The Zealot <zod zod.zod> writes:
https://forum.dlang.org/post/sxqwowayftguwtroluli forum.dlang.org

On Thursday, 2 December 2021 at 20:23:42 UTC, Dennis wrote:

 I love enums and think they could use some more love in D, but 
 I'm skeptical whether this particular thing can be made to work 
 in D without introducing edge cases and complexity.

 On Thursday, 2 December 2021 at 19:44:07 UTC, russhy wrote:

 That's a feature i long desired, and i'm pretty envious of the 
 languages that have it implemented, to name a few: Zig/Odin/Jai


 Don't know about Odin/Jai, but Zig does not have function 
 overloading / UFCS / template functions, so it doesn't have to 
 deal with D's existing complex baggage. The DIP should figure 
 out what happens in these situations:



Typing out those enums is annoying, but i have to say, i prefer 
it this way. it makes the code so much easier to understand 
later, as you don't have to guess which enum is actually used.

you can always alias the enums into global scope too, if you want 
to have short names.

So i'm more against adding this to the language.
Jun 30 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2022 at 11:06:31 UTC, The Zealot wrote:


 you can always alias the enums into global scope too, if you 
 want to have short names.


E.g.,

```D
enum expandEnum(EnumType, string fqnEnumType = EnumType.stringof) 
= (){
     string expandEnum;
     foreach(m;__traits(allMembers, EnumType)) {
         expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "." ~ 
m ~ ";";
     }
     return expandEnum;
}();

enum Color {
     red,
     green,
     blue,
     yellow,
     orange,
     black,
     white,
}
mixin(expandEnum!Color);

void main() {
     auto c = green;
     writeln(c);
}
```
Jun 30 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 30 June 2022 at 11:22:40 UTC, Mike Parker wrote:

 On Thursday, 30 June 2022 at 11:06:31 UTC, The Zealot wrote:


 you can always alias the enums into global scope too, if you 
 want to have short names.


 E.g.,

 ```D
 enum expandEnum(EnumType, string fqnEnumType = 
 EnumType.stringof) = (){
     string expandEnum;
     foreach(m;__traits(allMembers, EnumType)) {
         expandEnum ~= "alias " ~ m ~ " = " ~ fqnEnumType ~ "." 
 ~ m ~ ";";
     }
     return expandEnum;
 }();

 enum Color {
     red,
     green,
     blue,
     yellow,
     orange,
     black,
     white,
 }
 mixin(expandEnum!Color);

 void main() {
     auto c = green;
     writeln(c);
 }
 ```


This is exactly why we need it to be implemented, to avoid 
putting things in the global scope and therefore leaking

It better to make use of the type system and be a little more 
cleaner without having to rely on mixin/template/imports

It should just work
Jun 30 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2022 at 11:26:01 UTC, ryuukk_ wrote:


 This is exactly why we need it to be implemented, to avoid 
 putting things in the global scope and therefore leaking


I think "need" is a strong word here. I'm arguing we don't "need" 
it. I understand some people want it.


 It better to make use of the type system and be a little more 
 cleaner without having to rely on mixin/template/imports

 It should just work


Why should it just work, though? What justifies the potential 
confusion of having two different meanings for `.foo` when we 
already have `with`, and `auto`, and the ability to mixin aliases 
for those who really, really, want it.

To be clear, I do think adding this feature with the proposed 
syntax would be a mistake because it's one more potential point 
of confusion for new users. But on a personal level, I'm 
ambivalent. If it were added, I'd say "meh" and move on. I'm just 
pushing for some strong justification.
Jun 30 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 30 June 2022 at 11:32:06 UTC, Mike Parker wrote:

 On Thursday, 30 June 2022 at 11:26:01 UTC, ryuukk_ wrote:


 This is exactly why we need it to be implemented, to avoid 
 putting things in the global scope and therefore leaking


 I think "need" is a strong word here. I'm arguing we don't 
 "need" it. I understand some people want it.


 It better to make use of the type system and be a little more 
 cleaner without having to rely on mixin/template/imports

 It should just work


 Why should it just work, though? What justifies the potential 
 confusion of having two different meanings for `.foo` when we 
 already have `with`, and `auto`, and the ability to mixin 
 aliases for those who really, really, want it.

 To be clear, I do think adding this feature with the proposed 
 syntax would be a mistake because it's one more potential point 
 of confusion for new users. But on a personal level, I'm 
 ambivalent. If it were added, I'd say "meh" and move on. I'm 
 just pushing for some strong justification.



``.foo`` is just syntax, it could be ``_.foo``


It's like

```int myInt = int(42);```


Why do i need to be repetitive here?

Also the goal is not to remove the ability to do 
```Color.orange``` it is to leverage the type system to avoid 
having to be repetitive when it is not needed, like in the flags 
example


```MyFlags flags = .A | .B | .C | .D | .E | .F;```
Jun 30 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2022 at 11:40:31 UTC, ryuukk_ wrote:


 It's like

 ```int myInt = int(42);```


 Why do i need to be repetitive here?


You don't. I'm not sure of the point you're making here. Integer 
literals don't have namespaces. Named enums do.


 Also the goal is not to remove the ability to do 
 ```Color.orange``` it is to leverage the type system to avoid 
 having to be repetitive when it is not needed, like in the 
 flags example


 ```MyFlags flags = .A | .B | .C | .D | .E | .F;```


Yes, I understand the goal.

I'd rather see an enhancement to `with` that would allow it in 
declarations. Just off the top of my head, something like:

```d
with(.MyFlags) flags = A | B | C;
```

That would not create a scope, and it would have to be usable in 
module-scope initializers. `with` already means "prefix this type 
to fields that fit". Here it just goes one step further and 
allows for the type of the declaration to be inferred.
Jun 30 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 30 June 2022 at 11:53:16 UTC, Mike Parker wrote:

 I'd rather see an enhancement to `with` that would allow it in 
 declarations. Just off the top of my head, something like:

 ```d
 with(.MyFlags) flags = A | B | C;
 ```

 That would not create a scope, and it would have to be usable 
 in module-scope initializers. `with` already means "prefix this 
 type to fields that fit". Here it just goes one step further 
 and allows for the type of the declaration to be inferred.


This is not as clean as just this:

     MyFlags flags = .A | .B | .C | .D | .E | .F;


I feel it's much easier to read, there is no noise

Maybe the improvement of with could come handy when pairing it 
with ```auto`` uses where the typesystem can't guess what you 
give it to him

But they are different features, both are valid imo
Jun 30 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 30 June 2022 at 12:02:15 UTC, ryuukk_ wrote:

 On Thursday, 30 June 2022 at 11:53:16 UTC, Mike Parker wrote:

 This is not as clean as just this:

     MyFlags flags = .A | .B | .C | .D | .E | .F;


 I feel it's much easier to read, there is no noise


I don't. Hijacking existing syntax without change so that it 
means something else in a different context isn't clean at all.

And opinion is what it comes down to. I'm sure we can each find 
several people who'd agree with our opposing views on this. Any 
DIP is going to have to have a stronger justification than that.

Considering how `with` currently doesn't work for this case is a 
good starting point for finding a justification. (Then again, 
that's what led me to thinking it's better to enhance `with` 
instead, and I may not be the only one who goes there, so that's 
something else to consider in the DIP).

Anyway, just wanted to throw my thoughts out there. If you do get 
a DIP submitted, good luck!
Jun 30 2022
parent reply max haughton <maxhaton gmail.com> writes:
On Thursday, 30 June 2022 at 12:13:53 UTC, Mike Parker wrote:

 On Thursday, 30 June 2022 at 12:02:15 UTC, ryuukk_ wrote:

[...]


 I don't. Hijacking existing syntax without change so that it 
 means something else in a different context isn't clean at all.

 And opinion is what it comes down to. I'm sure we can each find 
 several people who'd agree with our opposing views on this. Any 
 DIP is going to have to have a stronger justification than that.

 Considering how `with` currently doesn't work for this case is 
 a good starting point for finding a justification. (Then again, 
 that's what led me to thinking it's better to enhance `with` 
 instead, and I may not be the only one who goes there, so 
 that's something else to consider in the DIP).

 Anyway, just wanted to throw my thoughts out there. If you do 
 get a DIP submitted, good luck!


with expressions are something we would benefit from (and I have 
implemented...). I'll write a DIP at some point.
Jun 30 2022
parent The Zealot <zod zod.zod> writes:
On Thursday, 30 June 2022 at 12:37:41 UTC, max haughton wrote:

 On Thursday, 30 June 2022 at 12:13:53 UTC, Mike Parker wrote:

 [...]


 with expressions are something we would benefit from (and I 
 have implemented...). I'll write a DIP at some point.


+1, yes please
Jun 30 2022