ranges of characters and the overabundance of traits that go with them

[Jack Stouffer via Digitalmars-d]

On Sunday, 12 March 2017 at 03:23:21 UTC, Jonathan M Davis wrote:
> ...

First off, I'd like to point out that creating specific overloads 
for alias this-ed structs is a bad idea, because you just have to 
ask the user to do this

MyCustomType { string b; alias b this; }

MyCustomType a;
foo!(string)(a);

instead of

MyCustomType a;
foo(a);

And I think making the conversion on the user is better, because 
once we go down the rabbit hole of offering custom template 
support for user defined alias this-ed types, there's almost no 
bottom. You have to do the same thing to every templated function 
that uses traits like isNumeric, isPointer, etc.

So with that in mind, your proposal for alias this overloads of

> auto foo(C)(C[] str)
>     if(isSomeChar!C)
> {...}

Isn't really helpful for either because it still clutters code 
with an extra overload. I think the problem we need to accept is 
that alias this and template will always be sort of oil and water.

I don't know if we should change the current overloads, as people 
complained with std.file was range-ified and their code using 
DirEntry broke. That's honestly what started this whole mess, and 
honestly in hindsight we should have marked the issue as won't 
fix and told them to use the above method. But people (including 
me) wanted the regression fixed which is totally understandable.

Maybe we should deprecate the isConvertibleToString overloads, 
maybe not. But we really shouldn't add more.

>As such, I think that code using isSomeString in a context where 
>an
>enum would pass needs to either be changed so that the function
>accepts only strings and uses !is(S == enum) to prevent enums 
>from passing

How much longer until we're at "Effective D: 55 things you 
shouldn't do because it's buggy and you don't know it".

*sigh* I know what my PRs are going to be for the next two weeks.

> So, that could be repeated a fair bit in templated code. We 
> _could_
> shorten that to something like isSomeCharRange!R, but as soon as
> you need a forward range or greater, you're going to end up with
> something like

> isForwardRange!R && isSomeCharRange!R
> whereas right now it would be
> isForwardRange!R && isSomeChar!(ElementType!R)

Well, that kills that idea, doesn't it?

> Consider changing isSomeString and isNarrowString so that they 
> are false
> for enums - since they really should be - but we probably can't 
> do that
> without breaking at least some code (albeit mostly code that's 
> going to
> be buggy anyway).

Can't agree here. We don't know how much code we'd be breaking. 
The move towards deprecation of old behavior is the best for 
users, and that's not really possible here. The best thing to do 
is make the docs very explicit.

> If we don't make that change, we should consider adding
> isExactSomeString to std.traits

Also disagree. Making more traits on top of an already confusing 
situation is a non-starter for me. Again, I think we just need to 
make the docs better here.