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