No we should not support enum types derived from strings

Adam D. Ruppe destructionator at gmail.com
Fri May 7 20:07:06 UTC 2021


On Friday, 7 May 2021 at 18:44:26 UTC, Steven Schveighoffer wrote:
> The end result of something like you allude to would result in 
> nearly all of phobos NOT working with arrays.

int[5] arr;
arr.sort(); // fails, you need to use []

Array!int arr;
arr.sort(); // fails, you need to use []

some random phobos functions special-case this to make it work 
which is the real wtf and those should be undone, just get the 
user to slice a static array.

So I'd just make it all consistent.


But tbh I don't feel that strongly about it... except for string. 
string should no longer be a range. Delete its popFront overload 
and let the user pick byCodeUnit or byCodePoint or whatever. Just 
rip that band aid right off.

Just even for the others, even if the [] was deemed unacceptable, 
i don't love the ufcs solution.

So many people try to do freestanding functions for other types, 
inspired by the phobos popFront.. and isInputRange fails because 
phobos itself must import the ufcs module. Other new people do 
foo.empty and it fails because they didn't import the module.

So like even if the behavior remained the same as today, I'd like 
to define it a little differently.

but meh dont wanna continue too far down this particular thing 
since it is the part of my rant i care the least about.


More information about the Digitalmars-d mailing list