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

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.

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

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

On Wednesday, 23 November 2022 at 15:21:07 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
    }
};

AttackType attack_type = .MELEE;


(..)


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

auto attack_type = AttackType.MELEE;

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

struct Action
{
    AttackType attack_type;
}

// no auto here

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;

}

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

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?

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.

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

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


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

}

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

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

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.

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

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