No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/10/21 1:09 PM, Joseph Rushton Wakeling wrote:
> On Monday, 10 May 2021 at 04:21:34 UTC, Andrei Alexandrescu wrote:
>>> Popping the head out of an enum value ought to be a string, not that 
>>> enum's value. I don't really see where the problem is here, this is 
>>> subtyping 101.
>>
>> 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.
> 
> This feels a bit like the real problem might be in the conflation of the 
> container (the enum or the string) and the range?
> 
> Cf. the way this is handled in Rust, where there is a clear distinction 
> between a container, versus an iterator over that container:
> https://doc.rust-lang.org/rust-by-example/flow_control/for.html
> 
> Note also the different ways that the iterator can be generated: either 
> using a reference to the container itself, or by moving the container 
> into the iterator so the container itself is consumed by the iteration.

True, D has only "orphan" ranges, no containers. std.container is not 
working out and with current D technology we can't define containers 
that work with safe/pure/nogc at the same time (two out of three we can).

If you consider the enum string value a container and the string 
extracted from it a range of that container, I think that would be a 
valid way to look at the matter.