Relaxing the definition of isSomeString and isNarrowString

[Jonathan M Davis via Digitalmars-d]

On Sunday, 24 August 2014 at 01:06:31 UTC, Andrei Alexandrescu 
wrote:
> Currently char[], wchar[], dchar[] and qualified variants 
> fulfill the requirements of isSomeString. Also, char[], wchar[] 
> and qualified variants fulfill the requirements of 
> isNarrowString.
>
> Various algorithms in Phobos test for these traits to optimize 
> away UTF decoding where unnecessary.
>
> I'm thinking of relaxing the definitions to all types that 
> fulfill the following requirements:
>
> * are random access ranges
> * element type is some character
> * offer .ptr as a @system property that offers a pointer to the 
> first character
>
> This would allow us to generalize the notion of string and 
> offer optimizations for user-defined, not only built-in, 
> strings. Thoughts?

I don't know. My first reaction is to be very, very worried about 
this. We made it so that isSomeString, isIntegral, etc. test for 
the specific type and not implicit conversion precisely to avoid 
problems where the type is assumed to be one of the built-in 
types, and the code then does weird things or just doesn't 
compile.

If we had done this with isSomeString originally, I'm sure that 
we could make it work, but you're talking about a type that isn't 
an array, and I expect that there's a lot of code out there that 
assumes that something that passes isSomeString is an array. And 
there's a good chance that a lot of the functions that do won't 
react well to a user-defined type.

I think that if we go that route, we should probably create a new 
trait for it rather than reuse isSomeString.

In addition, I'd be very concerned about using ptr like that, 
because the main use case for that aside from trying to avoid 
bounds checks is to pass to a C function, and that's going to 
need ptr to give you an actual array, in which case, I start 
wondirng why we're not just using arrays.

Also, what optimizations are you looking for here? To avoid 
auto-decoding? Something else? A lot of the 
compiler/druntime/Phobos devs are coming to the conclusion that 
the auto-decoding was a mistake and that we should look at 
removing it if we can and change it so that strings are treated 
as ranges of their element type rather than dchar. I'm even in 
the process of working on a DIP for just that, and making the 
transition would be nowhere near as bad as I was initially 
expecting it to be. I think that we can actually do it fairly 
cleanly. If we did that, then I'm not sure what gain there would 
be in doing something like this to isSomeString or even in 
creating a new trait. Simply having a random-access range whose 
element type is a character type would do it already. The only 
part that it might miss out on is using ptr to skip bounds 
checking, and I don't know how much sense that makes with a 
user-defined type anyway given that ptr would have to be giving 
you a pointer to an array to work wherever ptr works for arrays.

- Jonathan M Davis