www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - String manipulation

reply 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
Oct 21 2015
parent reply 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.
Oct 21 2015
parent reply 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
Oct 22 2015
parent 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)
{
}
Oct 23 2015