https://forum.dlang.org/post/sxqwowayftguwtroluli@forum.dlang.org

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

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.

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

E.g.,

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);
}

On Thursday, 30 June 2022 at 11:22:40 UTC, Mike Parker wrote:

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

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

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

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.

On Thursday, 30 June 2022 at 11:32:06 UTC, Mike Parker wrote:

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

On Thursday, 30 June 2022 at 11:40:31 UTC, ryuukk_ wrote:

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

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:

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.

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

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

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

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

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

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!

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.

On Thursday, 30 June 2022 at 12:37:41 UTC, max haughton wrote:

+1, yes please