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

I was always wondering why this doesn’t “just work” in D:

enum Color { red, orange }
Color color = orange;

This is a major source of frustration when porting from C, where enum assignment does work like this (but, unlike in D, enum member names must be unique).

Usually D compiler is smart enough to evaluate the type of the right-hand of an assignment. But for some reason it’s not the case with enums. I was under impression that this is a deliberate (although questionable) design to avoid some bugs rather some technical limitation.

On Thursday, 30 June 2022 at 09:08:30 UTC, Ogi wrote:

enum Color { red, orange = 3 }

int orange = 1;

Color color = orange;
// what is color?
// or what about
auto color = orange;
// What is color?
// or this:
auto color = cast(int)orange;
// What is color?

Arguably each of these can be defined behavior and can be solved, but what defined behavior is correct depends entirely on what people expect to be true, and that's very different depending on the type of project(s) people work on, what language background they come from etc.

For me the first one will be 1, because I believe a defined value should override an enum value if specified, but this may be different from others.

The second one is the same, the type should be int and not Color.

The third one has the type int as well and will obviously use the int variable named orange in my expectation.

However I can see the argument for other people wanting the first one to be a compiler error because it's ambiguous, or even that you cannot override enum values and thus it will take the value from Color.

All of these behavior are correct and neither is wrong, as it all just depends on how one think about programming in terms of types, values, rules etc.

I don't think D could ever settle on a single rule here that a majority would agree upon.

On Thursday, 30 June 2022 at 09:19:15 UTC, bauss wrote:

C++ solves this with enum class for stricter enumeration semantics.

On Thursday, 30 June 2022 at 09:50:34 UTC, Ola Fosheim Grøstad wrote:

I think that again depends on what one expects to happen, as it only solves it if that's the perceived correct behavior.

On Thursday, 30 June 2022 at 09:19:15 UTC, bauss wrote:

enum Color { red, orange = 3 }

int orange = 1;

Color color = orange;
// what is color?
// or what about
auto color = orange;
// What is color?
// or this:
auto color = cast(int)orange;
// What is color?

the goal is not to copy c/c++, it's to be smarter, they are not globals

it's not .orange therefore it is your variable, it if were with the dot, it'd take what ever is in the enum

same, it's not .orange therefore it's 1, if it where with the dot, it's compile error telling you to be more explicit

it's not .orange therefore it is your variable, it if were with the dot, it'd take what ever is in the enum, then apply the cast

I don't know it seems pretty obvious to me

This feature is too good to not have

On Thursday, 30 June 2022 at 10:51:31 UTC, ryuukk_ wrote:

My problem with this is it is not obvious at all to me. When I see .foo, I immediately think "foo is in the parent scope", as that what is what it means right now in D. If we're suddenly seeing .foo at module scope, now I've got a fault in my wiring; .foo suddenly has different meanings depending on the scope in which it's used.

I mean, maybe I could get used to it if I used it. But I don't see myself using it at all.

Not saying I'm against the feature, I just don't understand why auto color = Color.orange is a problem and how Color color = .orange is better. Because of four fewer characters?

On Thursday, 30 June 2022 at 10:58:37 UTC, Mike Parker wrote:

What it seems like it's trying to solve is this:

SomeEnum.a | SomeEnum.b | SomeEnum.c

So you could instead do:

.a | .b | .c

But much like you I don't think that's at all clarified, maybe I would settle for something like this:

SomeEnum(a | b | c) as that clearly tells you it's SomeEnum and then it's clear you're picking the values from that, so a, b and c will always be from SomeEnum.

But personally I don't really like that syntax either as it clashes too much with struct ctors and/or function calls.

So I don't have an actual good solution, so I guess in the end I'm not for any changes.

Indeed, this example doesn't make much sense, but the ony i posted on the github shows exactly why we need it

set_my_flag( MySuperLongName.MyFlagA |  MySuperLongName.MyFlagB | MySuperLongName.MyFlagC | MySuperLongName.MyFlagD | MySuperLongName.MyFlagE | MySuperLongName.MyFlagF );

vs

set_my_flag( .MyFlagA |  .MyFlagB | .MyFlagC | .MyFlagD | .MyFlagE | .MyFlagF );

One could argue to use with

But what about places where it can't be used? and it is counter productive, if the goal is to remove repetition, why introduce more?

It already is explicit, and checked with the type system

I suggest trying languages that have that feature and see how practical, and just better enums feel to use

I see myself still relying on constants to emulate enums... in D, because of that, that's not good

On Thursday, 30 June 2022 at 11:32:42 UTC, ryuukk_ wrote:

set_my_flag( MySuperLongName.MyFlagA |  MySuperLongName.MyFlagB | MySuperLongName.MyFlagC | MySuperLongName.MyFlagD | MySuperLongName.MyFlagE | MySuperLongName.MyFlagF );

set_my_flag( .MyFlagA |  .MyFlagB | .MyFlagC | .MyFlagD | .MyFlagE | .MyFlagF );

Meh... if you need to specify that many enum values then perhaps you just need a new field with all those values.

On Thursday, 30 June 2022 at 09:19:15 UTC, bauss wrote:

enum Color { red, orange = 3 }

int orange = 1;

Color color = orange;
// what is color?
// or what about
auto color = orange;
// What is color?
// or this:
auto color = cast(int)orange;
// What is color?

it's like asnwsering

int resultValue = 42;

int resultValue()
{
     return 5;
}


void main()
{
     writeln(resultValue);

}

in case of ambiguity, the compiler already smart enough to give an error:

onlineapp.d(6): Error: function `onlineapp.resultValue` conflicts with variable `onlineapp.resultValue` at onlineapp.d(4)

same could be applied for enums

and here clearer example for errors:

enum Color { orange }

int orange = 5;

void main()
{
    auto color = .orange;  <--- it obviously pick 5; it can't deduce it is an enum
    Color color = .orange; <--- it obviously pick orange, it already expect an enum
    int color =  .orange;  <--- it obviously pick 5, it already expect an int
}

No need to overthing it, D is typesafe language, it'll work