• Andrei Alexandrescu (6/6) Oct 21 2015 I just submitted a note on a commit:
• Kagamin (2/2) Oct 21 2015 https://issues.dlang.org/show_bug.cgi?id=15027 It's a general
• Jonathan M Davis (17/19) Oct 22 2015 IMHO, alias this is a disaster for templated code - e.g. it's way
• Kagamin (20/20) Oct 23 2015 I think, it's more a problem with type inference, which is either

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

I just submitted a note on a commit:

https://github.com/D-Programming-Language/phobos/commit/8dc29bff62fc7c2f806e08cccc01be55923fa83b

It seems we need a better angle on string support. E.g., what qualifies 
as a "string-like" data structure? Adding individual functions for a 
bunch of cases doesn't seem like the right approach.


Andrei

Kagamin <spam here.lot> writes:

https://issues.dlang.org/show_bug.cgi?id=15027 It's a general 
problem with alias this being an incomplete subtyping.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Wednesday, 21 October 2015 at 11:25:17 UTC, Kagamin wrote:
 https://issues.dlang.org/show_bug.cgi?id=15027 It's a general 
 problem with alias this being an incomplete subtyping.

IMHO, alias this is a disaster for templated code - e.g. it's way 
too easy for something to pass a template constraint thanks to 
alias this but then not actually be converted via the alias in 
the function, so it either ends up not compiling or having weird 
results. And as the recent problems with rangifying functions 
show, taking a function that accepts explicit types and changing 
it to so that it's templated and thus using a template constraint 
rather than explicit types is almost certainly going to break 
code that involves alias this. At this point, I think that we're 
just stuck with it, but honestly, if we could go back, I'd 
strongly argue for ditching the ability to add implicit 
conversions to a type and see how far we could get without them. 
Sure, they can be useful upon occasion, but I really don't think 
that they're worth the pain overall - especially when you use 
templates as heavily as we do.

- Jonathan M Davis

Kagamin <spam here.lot> writes:

I think, it's more a problem with type inference, which is either 
exact match or nothing. I once had an idea of customized type 
inference, which is able to replace the matched type in the 
process (concepts probably can't do that, do they?), it also 
allows more constrained type inference than auto, which would 
result in a more readable code like `InputRange!int r = get();`. 
But as it's likely a complex feature and language is stabilized, 
I didn't bother to write a DIP.

 inference
template PseudoString(T)
{
   static if(__traits(compiles, string s=T.init))
     alias PseudoString=string;
   else
     alias PseudoString=NoMatch;
}

//signature becomes (string path) - type was inferred
bool isDir()(PseudoString path)
{
}