No we should not support enum types derived from strings

Paul Backus snarwin at gmail.com
Mon May 10 13:30:52 UTC 2021


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.

popFront doesn't return a value, it mutates. So `r` before 
popFront and `r` after popFront must be the same type, because 
they are the same variable.

If popFront for a string enum is `r = r[1 .. $]`, and typeof(r[1 
.. $]) != typeof(r), then it doesn't work, and string enums can't 
be ranges (from which it follows that they are not 
Liskov-substitutable for strings).


More information about the Digitalmars-d mailing list