November 23

On Wednesday, 23 November 2022 at 04:43:16 UTC, IchorDev wrote:

>

Aliasing requires figuring out a good alias name, polluting the namespace, and just feels like a hack.

Naming stuff is a technique that has been used in programming languages for quite a while. It's a feature I can't do without. Finding good names for things is indeed important. And polluting the namespace is bad. I don't know what that has to do with this DIP or with alias. I also don't agree that naming things is a hack.

>

It's nice that D lets you, but I think a dedicated mechanism to reduce typing fatigue is better than obfuscation.

Then find a better editor/IDE. One that has copy and paste.

>

"What's this... M?" searches library "What? This isn't in here!" searches codebase "Oh, it's an alias of Magic. Who did this?"
vs
"$? Oh, this function call uses ETI. Let me see its declaration..." checks declaration "Okay it's Magic"

This is absurd. The DIP proposes using the same $ to refer to any enum. If someone is confused by an explicit name, by definition they're going to be confused by a generic $.

November 23

On Wednesday, 23 November 2022 at 15:21:07 UTC, ryuukk_ wrote:

>

On Wednesday, 23 November 2022 at 14:21:23 UTC, deadalnix wrote:

>

On Wednesday, 23 November 2022 at 13:41:12 UTC, ryuukk_ wrote:

>
// verbose API, readable
struct SuperLongStruct
{
    struct SuperLongInnerStruct
    {
        enum SuperLongEnum
        {
            VALUE_A, VALUE_B
        }

        SuperLongEnum super_long_flags;
    }
    SuperLongInnerStruct some_data;
}

// oh shoot

SuperLongStruct super_long_struct = {
    some_data: {
        super_long_flags:  SuperLongStruct.SuperLongInnerStruct.SuperLongEnum.VALUE_A | SuperLongStruct.SuperLongInnerStruct.SuperLongEnum.VALUE_A
    }
};

// oh nice!

SuperLongStruct super_long_struct = {
    some_data: {
        super_long_flags: .VALUE_A | .VALUE_A
    }
};

Try alias E = SuperLongStruct.SuperLongInnerStruct.SuperLongEnum;

>
AttackType attack_type = .MELEE;


(..)


switch (attack_type)
{
    case .MELEE:
    break;
}



now your variable name carry more and proper information about what it is,

auto attack_type = AttackType.MELEE;

switch (attack_type) with(AttackType) {
    case MELEE:
    break;
}
struct Action
{
    AttackType attack_type;
}

// no auto here

in your switch, did you read it?

switch attack_type with AttackType

this is not appealing and is the noise and repetition that needs to be suppressed

i was verbose when i declared my variable name, that's enough

and you didn't read my other comment

why should i declare an alias? it leaks the symbol to the scope, it is another symbol that i need to remember when i refactor, and it adds cognitive load when i read my whole module, too much gymnastic and scope bloat

now this example:

switch (action.attack_type) with(AttackType) {
    case MELEE:
        if (action.weapon_type == SuperLongType.InnerType.SWORD)
            (...)
    break;

}



switch (action.attack_type) with(AttackType) with(SuperLongType.InnerType) with(SuperLongType.AnotherInnerType) {
    case MELEE:
        if (action.weapon_type == SWORD)
            (...)


        if (action.buff_type == STR_UP)
            (...)
    break;

}

Yeah no thanks..

There it's miles better, you don't need no alias to workaround anything that bloats scope and adds superfluous and unnecessary cognitive load, you read the variable name and you know what you deal with

switch (action.attack_type) {
    case MELEE:
        if (action.weapon_type == .SWORD)
            (...)


        if (action.buff_type == .STR_UP)
            (...)
    break;

}
November 23

On Wednesday, 23 November 2022 at 15:13:09 UTC, 12345swordy wrote:

>

That doesn't work when interacting with existing c code base here.

Funny thing is, because C enums being unqualified and not strongly typed was considered a problem, C got into the habit of repeating every enum's type name in every of its values e.g.

enum IMG_INIT { IMG_INIT_jpg, IMG_INIT_png }

P.S. of course it doesn't work for that. But interoperating with C isn't the problem here, because C enums don't map to D enums but to integers?

November 23

On Wednesday, 23 November 2022 at 15:26:46 UTC, ryuukk_ wrote:

>
switch (action.attack_type) {
    case MELEE:
        if (action.weapon_type == .SWORD)
            (...)


        if (action.buff_type == .STR_UP)
            (...)
    break;

}

Inconsistency. Should be with/without dot in either case.

November 23

On Wednesday, 23 November 2022 at 16:30:56 UTC, RTM wrote:

>

On Wednesday, 23 November 2022 at 15:26:46 UTC, ryuukk_ wrote:

>
switch (action.attack_type) {
    case MELEE:
        if (action.weapon_type == .SWORD)
            (...)


        if (action.buff_type == .STR_UP)
            (...)
    break;

}

Inconsistency. Should be with/without dot in either case.

You are nitpicking, that's a forum quote issue, it was my code that he quoted and edited, all my examples have the dot

November 23
>

This DIP proposes that ETI in D should use the syntax $enumMember.
Why not extend this to apply to all things inside namespaces such as static class members, or the items of a statically imported package?

November 23

On Wednesday, 23 November 2022 at 05:01:58 UTC, IchorDev wrote:

>

Nobody mentioned it here yet, so I figured I'd point out that the wonderful UplinkCoder has made a partial implementation of this DIP.
You can find the PR for it here: https://github.com/dlang/dmd/pull/14650

They have implemented a great deal of the proposed features in less than a day. They said ETI overloaded functions are incomplete and may take some time to finish, but I think that their progress so far demonstrates just how simple a feature ETI really is.

Thanks for mentioning it.

I think overloaded functions should work now.

The cause of the issue turned out to be a straightforward bug in my code.
which caused the type to be set even if the enum member inference failed.
Which meant the expression got typed as the first enum declared in the.
Simply moving the setting of the type until after the check for a vaild inference;
Fixed that bug.

TLDR; the PR should now implement the DIP largely the way it's discribed.

November 23

On Wednesday, 23 November 2022 at 17:24:53 UTC, Ishax wrote:

> >

This DIP proposes that ETI in D should use the syntax $enumMember.
Why not extend this to apply to all things inside namespaces such as static class members, or the items of a statically imported package?

100% this (which would still be a bad idea imho, but not as bad as making this work just for enums)

November 23
On Tuesday, 22 November 2022 at 09:37:43 UTC, bauss wrote:
>
> If it's not implemented with .identifier then I will oppose it.
>

+1
and it's a feature that was desperately needed anyway.

November 23
On Wednesday, 23 November 2022 at 22:16:35 UTC, Guillaume Piolat wrote:
> On Tuesday, 22 November 2022 at 09:37:43 UTC, bauss wrote:
>>
>> If it's not implemented with .identifier then I will oppose it.
>>
>
> +1
> and it's a feature that was desperately needed anyway.

that was *not* desperately needed