On Sunday, 11 August 2024 at 07:11:01 UTC, Richard (Rikki) Andrew Cattermole wrote:

So DIP1000 won’t become a thing, or it’ll just have a different implementation?

On Saturday, 10 August 2024 at 15:41:28 UTC, ryuukk_ wrote:

Yes please thank you. I'd even lean towards excluding the . if at all possible but I assume people predict too many potential conflicts in other code? Either way I'd definitely like to see this working as a preview, it's a lot easier to see if it Just Works or Just Doesn't to try it than to keep it forever locked in council session limbo.

On Monday, 12 August 2024 at 08:58:59 UTC, cc wrote:

It would be too ambiguous. If you write a type-inferred enum member that has the same name as a local variable, what happens? The fact that there’s more than one answer means that the programmer can’t be certain without looking it up; wasting their time to use a convenience feature. It’s variable shadowing but with types—bleh! Having a prefix makes your intention explicit, and later you don’t have to contemplate whether you’re looking at a variable/function call, or type inference.

Well you’re welcome to submit a new PR for the existing implementation but with it locked behind a preview…

On Monday, 12 August 2024 at 11:47:54 UTC, IchorDev wrote:

I scold myself for using a local variable named the same as an enum member. s'why I like to use all caps for my enums, saves my valuable time so I don't have to look things up ;)
But the compiler already yells at people for ambiguous function usage anyway, worst case scenario is you just have it bark "assigning symbol x to enum type conflicts with local variable x, please use explicit enum reference y.x or cast(y) x to use local variable"
Worst worst case scenario is the user has a local variable of the same type as the enum itself with the same name as one of the enum members in which case he needs to be smacked and made to stand in the front of the class for doing something so silly. And then cast the local to its own type to force it to compile.

Will take me a minute to get up to speed on mucking with the compiler but maybe I'll give it a shot next rainy afternoon

On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:

So I considered it a bit, and here's a scenario I could find plausible:

enum SqlResult { ok, error, constraint, } // inferred numeric basetype enum

bool ok;
string error;

SqlResult result;
result = constraint; // no problem
result = ok; // Ambiguous assignment to enum: use explicit SqlResult.ok, or
             // cast(SqlResult) ok to assign local variable
	result = SqlResult.ok; // explicit enum member
	result = cast(SqlResult) ok; // casts bool to SqlResult
result = error;  // actually, this should be ok, because you couldn't cast a string
                 // to a numeric enum anyway, but we could be picky about it anyway


SqlResult ok;
SqlResult result;
result = ok; // This is where things get silly. If you do this, you did something silly.
             // It could conceivably happen somewhere in a billion lines of code, but
             // if it does, the compiler should tell you you're silly. No one is going
             // to be sufficiently harmed by being informed that this is bad practice
             // and forced to throw in a cast() to make their intentions clear.

Globals should already be sorted out by existing syntax. We have the "price to pay" of typing in an explicit Enum. or cast(Enum) but this only comes about if we happened to have a local variable by the same name as an enum member. If you just don't do that, you aren't stripping yourself of any convenience. And if you do, well, what do you want? The compiler can't read your mind ALL the time, but a lot of the time is better than none of the time, otherwise we wouldn't have auto, or template inference, or a whole bunch of other things.

On Wednesday, 14 August 2024 at 13:30:25 UTC, cc wrote:

You and no one else, you do it to yourself.

And apparently there are no women in the field of computer science.

Now let’s try to use the same syntax for type-inferred struct constructors:

MyStruct s = (1, 2, 3);

Oh look, a comma expression!