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

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

On Friday, 18 November 2022 at 19:33:05 UTC, H. S. Teoh wrote:

This could break pre-existing code, so it's a definite no unfortunately. I don't want to break working code just to add a convenient shortcut. That's like having a highway built through your house!

On Saturday, 19 November 2022 at 02:06:57 UTC, ryuukk_ wrote:

I've run into cases like this a LOT. C library bindings that have enums with ridiculously long redundant names like vegetable_t.vegetable_carrot are abundant.
Also yes I've used Vulkan's API... never again. My head still hurts.

On Saturday, 19 November 2022 at 04:22:39 UTC, Walter Bright wrote:

enum A { a; }
enum B { a; }

void f(A);
void f(B);

...
f($a + $a); // mentioned in the DIP as allowed
...

If you're sure that arithmetic and ETI won't mix for implementation reasons then I could explicitly prohibit it. My only apprehension is that ORing enum flags with ETI is very handy.

On Saturday, 19 November 2022 at 04:14:18 UTC, Walter Bright wrote:

Well dra(E.e); doesn't compile, so neither should dra($e) to my mind.

On Saturday, 19 November 2022 at 08:48:54 UTC, Dukc wrote:

If you're referring to me (I'm the DIP Author), then it's she/her.
The _ is a bit confusing. Would it be _.member? If so then I personally think $ is better because it's 1 keystroke fewer. I chose $ because its current use can peacefully co-exist with ETI and it's only two keystrokes, meaning that it beats writing a 2+ enum type name. If it was _member then it'd just look like a normal symbol.

On Saturday, 19 November 2022 at 08:49:31 UTC, Walter Bright wrote:

I'm up for changing it to something else, like I've said. It's just that I can't think of anything better except maybe #member, but I think # is reserved right?
:member would be cool but it reminds me of C++ and would be a nightmare in so many cases. %member is alright but it looks like an operator. What about ->member... actually nevermind I hate it.
\member???

I have mixed feelings about this. It's very hard to intuitively read that it's an enum member when it's written without any kind of affix at all, and it can't even work with overloaded functions. With some changes, I'd consider it.

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

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

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

D has good type system

first off, name properly your functions/types/variables

then about the problem you are raising:

attack_enemy(1, 10, 5);

void attack_enemy(int id, int damage, float modifier)
{}

How do you know the last parameter is a float?

to quote you: "now what the heck is this gratuitous obfuscation"

Now another example:

int currhp = player.hp;

is hp a variable? or is it a function that's gonna do some logic?, if that's a function, will it throw? will it, is it thread safe?

to quote you again: "now what the heck is this gratuitous obfuscation"

The DIP doesn't enforce you to omit the type name, it gives you the ability to omit it when the context is clear, let's you setup a long and verbose name without sacrificing readability of your code when you use it

NetworkState network_state = State.NetworkState.CONNECTED;

to quote you again: "now what the heck is this gratuitous obfuscation"

the repetition adds useless cognitive load, makes the line harder to read, and makes me want to give up proper type scoping (putting enum under the struct scope), and it encourages me to use shorter enum name, wich gives you poor APIs as a result

TOK enum in DMD codebase instead of SymbolTokenType

D is not dynamic typed, we should leverage the type system to encourage lean code without sacrificing readable APIs