On Wednesday, 26 April 2023 at 15:07:36 UTC, ryuukk_ wrote:

Your proposals were built on unrealistic examples and false dichotomies. If the only choice is 48-character informative names or two-character uninformative names, the problem is not the language.

On Wednesday, 26 April 2023 at 14:54:40 UTC, max haughton wrote:

Wow, didn't know about this PR exists. Thank you for sharing!

On Thursday, 27 April 2023 at 06:10:57 UTC, Basile B. wrote:

alias F = MySuperLongNameFlag;

auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);

I don't think it's a misconception. It's more like a complete lack of clarity. What would be the point of complexifying the language for the new programmer when you can just use an anonymous enum? This program runs just fine:

import std.stdio;

enum {
	A1,
	B1,
	C1,
	D1
}

enum {
	_A,
	_B,
	_C,
	_D
}

void main() {
	writeln(A1);
	writeln(_A);
	writeln(A1 == _A);
	
	auto flag = _B;
	switch(flag) {
		case _A:
			writeln("_A");
			break;
		case _B:
			writeln("_B");
			break;
		case _C:
			writeln("_C");
			break;
		case _D:
			writeln("_D");
			break;
		default:
			break;
	}
}

What's the point in using a named enum if you want an anonymous enum? The response when this question was asked was not "because [something where it matters]". It was instead to ignore the question, give an unrealistic example that was solved by the response, and insert a bunch of unhelpful hostility.

On Thursday, 27 April 2023 at 13:03:17 UTC, bachmeier wrote:

alias F = MySuperLongNameFlag;

auto flag = F.A | F.B | F.C | F.D;
set_flags(F.A | F.B | F.C | F.D);

import std.stdio;

enum {
	A1,
	B1,
	C1,
	D1
}

enum {
	_A,
	_B,
	_C,
	_D
}

void main() {
	writeln(A1);
	writeln(_A);
	writeln(A1 == _A);
	
	auto flag = _B;
	switch(flag) {
		case _A:
			writeln("_A");
			break;
		case _B:
			writeln("_B");
			break;
		case _C:
			writeln("_C");
			break;
		case _D:
			writeln("_D");
			break;
		default:
			break;
	}
}

what's the point? if you read the discussion that happened for the DIP you wouldn't ask the question

the goal is not to use an anonymous enum, the goal is to leverage the robust type system to avoid repeting yourself, wich is bad

Value value;
value.type = ValueType.STRING;

vs

Value value;
value.type = .STRING;

Read your code, would you read a book where each sentence would be a repetition of the previous one?

"Billy went to the town to buy some beer, as he arrived to the town to buy some beer he met Richard, as he arrived to the town to buy some beer Richard, that he just met, asked him how his wife was doing"

Do you write this?

float myfloat = float(1.0);

Or this?

float myfloat = 1.0;

Why would it be different for enums (or any other type)

Also i suggest you to try all kind of languages to expand your knowledge and to try out new UX that modern languages provide, there is no reason to refuse to understand other people's opinion only because you thought the existing rule is immutable because you can't give a critical opinion on it

On Monday, 1 May 2023 at 00:34:03 UTC, ryuukk_ wrote:

Value value;
value.type = ValueType.STRING;

Value value;
value.type = .STRING;

This is another case of the "complete lack of clarity" I wrote about in my earlier comment. With an anonymous enum you could write

value.type = STRING;

Maybe you have something deeper in mind, but that example does not make a case for changing the language. Rather than shouting, you should put together a better example.

I will let this conversation die. I don't think it's going to resolve anything (and I'm not the one that needs convincing anyway).

On Monday, 1 May 2023 at 14:03:51 UTC, bachmeier wrote:

value.type = STRING;

IRL people would use namespacing prefixes or actual namespaces anyway, so your example would look more like

value.type = VALUE_TYPE_STRING;