No we should not support enum types derived from strings

[Adam D. Ruppe]

On Friday, 7 May 2021 at 17:11:32 UTC, Steven Schveighoffer wrote:
> How do you say "I want to accept something that's a string, but 
> I want it as a string please"

Well, one way we can do that today is to have the template 
forward to a normal function, or a normal function forward to a 
template.

void format(T...)(const char[] s, T args) {
       format(asRangeOfDchar(s), args);
}

void format(Range T...)(Range r, T args) 
if(isAppopriateRange!Range) {
        // actual impl based on the range interface
        // and actually tbh I'd personally take another step
        // and collapse all these down even more.
}

Then a whole bunch of conversions are done to match `const 
char[]` and the template is then working with that entry point 
instead of the whole plate.

This of course assumes isAppropriateRange is false for anything 
that isn't actually already a range. And I'm assuming string is 
not already a range. Otherwise you enter back into the hell of 
not only saying what you accept, but having to exclude things too.


So let me rant.

I think it was actually a mistake for Phobos to UFCS shoe-horn in 
range functions on arrays too - this includes strings as well as 
int[] and such as well. Lots of new users ask why they can't do 
the same thing. And like Phobos took this opportunity to do silly 
things like autodecoding when we all hate now, but I don't think 
the freestanding ufcs range functions should exist at all.

Just have the user fetch a range out of the container. Then they 
get in that habit with other containers too and it moves a bunch 
of ugly code out of every consuming function.

Heck the `asRange` thing itself might have a variety of overloads 
it forwards to.


MyRange asRangeHelper(const char[] s) { return MyRange(s); }

auto asRange(T)(T t) { /* generic stuff */ }
auto asRange(T : const char[])(T t) { return asRangeHelper(t); } 
// let the language convert it in these specializations

and so on and so forth.



This is a half-baked rant im sure you can destroy at will. But 
like I'm pretty sure if we did develop this it would be nicer 
overall than what we have now.


> The answer is because there isn't a good way to do it.

And it is possible the language could insert some magic to make 
it easier if we really put our thinking caps on.