No we should not support enum types derived from strings

[Joseph Rushton Wakeling]

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.