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.
