Relaxing the definition of isSomeString and isNarrowString

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 24 05:30:02 PDT 2014


On 8/23/14, 7:05 PM, Jonathan M Davis wrote:
> 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.

I guess unittests are for that kind of stuff. One good start would be to 
see what kind of assumptions are made by algorithms specialized on 
isSomeString.

> 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.

Yah, that would be a safe path but would complicate checks.

> 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.

Because the abstraction I'm thinking of is reference counted.

> Also, what optimizations are you looking for here? To avoid
> auto-decoding? Something else?

It's just taking advantage of the work that's already been done in 
std.algorithm and elsewhere.

> 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.

As I wrote at length a few minutes ago, I think such a DIP would be a 
waste of time and energy. I encourage everyone to work on pushing things 
forward with new work instead of forever fiddling with what we have "for 
the last time".


Andrei



More information about the Digitalmars-d mailing list