No we should not support enum types derived from strings

[deadalnix]

On Tuesday, 11 May 2021 at 12:14:42 UTC, deadalnix wrote:
> On Tuesday, 11 May 2021 at 12:05:18 UTC, Andrei Alexandrescu 
> wrote:
>>> I'm not sure what's the problem is here. Do you have a 
>>> concrete example?
>>
>> Of course. A range must implement popFront with the signature:
>>
>> void popFront(ref SomeEnumString s) {
>>     ... please fill in the implementation ...
>> }
>
> That must be a type error, this is a feature, not a bug. This 
> is not expected to work.

I realize that this require further explanations.

The fact that B is a subtype of A doesn't imply that a type 
constructed from B is a subtype of that same construction using 
A. For instance,

A function() would be a subtype of B function(), the relation 
reversed in that example.

In your example, you are constructing a ref SomeEnumString and 
expecting it to be a subtype of string (or maybe ref string) but 
both are incorrect assumptions. This is because you can execute 
operation that require covariance as well as operation that 
require contravariance on a ref, therefore, it needs to be 
exactly the same type. This is hardly an exceptional situation, 
this also happens when taking an array, B being a subtype of A 
doesn't mean the B[] is a subtype of A[].

Interestingly, it is the case for const ref, or const arrays, 
which is where the push toward handling const ref differently 
comes from.

In any case, it is not expect from format that it modify teh 
pattern it takes as an input. In fact, it is a god damn compile 
time parameter, it is not mutable to begin with. It is therefore 
expected that this works.