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