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