No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/10/21 5:44 PM, deadalnix wrote:
> On Monday, 10 May 2021 at 12:19:07 UTC, deadalnix wrote:
>> On Monday, 10 May 2021 at 04:21:34 UTC, Andrei Alexandrescu wrote:
>>> So you have a range r of type T.
>>>
>>> You call r.popFront().
>>>
>>> Obvioulsly the type of r should stay the same because in D variables 
>>> don't change type.
>>>
>>> So... what gives, young Padawan?
>>>
>>> No, this is not subtyping 101.
>>
>> If you have a range of T, then you got to return a T. I'm not sure 
>> what's the problem is here. Do you have a concrete example?
>>
>> All I can think of are things like slicing and alike, and they should 
>> obviously return a string, not a T.
> 
> More to the point, consider this:
> 
> class String {
> private:
>      immutable(char)[] value;
> 
> public:
>      this(immutable(char)[] value) { this.value = value; }
> 
>      // ...
> }
> 
> class EnumString : String {
> public:
>      static EnumString value1() { return new EnumString("value1"); }
>      static EnumString value2() { return new EnumString("value2"); }
> 
> private:
>      this(immutable(char)[] value) { super(value); }
> }
> 
> While the implementation differs, conceptually, from a the theory 
> standpoint, this is the same.

No it isn't.

EnumString and String are reference types. A reference to an enum value 
does not convert to a reference to its representation. Very very very 
VERY different.

> This is using a subtype to constrain 
> instance of type (String here) to a certain et of possible values. When 
> using the subtype (EnumString) you have the knowledge that it is limited 
> to some value, and you lose that knowledge as soon as you convert to the 
> parent type.

One question that you keep not answering (Paul and I both asked it) is 
how you'd implement the range primitive popFront.

> But instead, we gets some bastardised monster from the compiler, that's 
> not quit a subtype, but that's not quite something else that really make 
> sens either. As expected, this nonsense ends up spilling into user code, 
> and then the standard lib, based on user constraints, and everybody is 
> left choosing between bad tradeof down the road because the whole house 
> of cards is built on shaky foundations.
> 
> The bad news is, there is already a language like this. It's called C++, 
> and it's actually quite successful. With all due respect to you and 
> Walter, you guys are legends, but I think there is also a bit of learned 
> helplessness coming from both of you due to a lifetime of exposure to 
> the soul corroding effects of C++.
> 
> This attitudes pervades everything, and most language constructs suffer 
> of some form of it in one way or another, causing a cascade of bad side 
> effects, starting with this whole thread. A few examples en vrac for 
> instance: DIP1000, delegate context qualifiers, functions vs first class 
> functions, etc...

I very much agree Walter and I have brought C++ bias into D, sometimes 
in a detrimental way.

> Back to the case of enum, it is obviously and trivially a subtype.

No it isn't. How many times do I need to explain that?

> In 
> fact, even the syntax is the same:
> 
> enum Foo: string { ... }

It doesn't matter. It's not a subtype.

> Handling enum strings should never have been a special that was added to 
> phobos, because it should never have been a special to begin with, in 
> phobos or elsewhere.

Clearly enums have their own oddities, most inherited from C++. Perhaps 
we should do what C++ did, add a new "enum class" construct that fixes 
its issues. But I don't know of a perfect design, and I very much would 
love to see one.