On Wed, Feb 15, 2017 at 09:03:46PM +0000, Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: > > I'd like to take a step back and devise a consistent taxonomy of these > > things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow strings > > > 2. not auto decoding arrays > > Wide strings > > > 3. static arrays > > Do these need to be called anything other than "static arrays"? Also, > they're not ranges, so they're usually tested with isStaticArray > > > 4. aggregates with an 'alias this' to a string > > isConvertibleToString > > > 5. ranges of characters > > Character range > > > 6. something convertible to a string > > Same as 4
This describes the current state of Phobos, but I think what Walter is driving at is, does it *have* to be this way? I think we can (and should) simplify this taxonomy to avoid needless duplication and also create a more consistent conceptual model of how Phobos deals with strings and string-like things. First of all, I think we should try out best to avoid treating arrays and character ranges differently. I know this is inevitable because we're still in a state where autodecoding can't be fully eliminated yet, but as far as possible, I think we should try to treat them the same way. (1) Functions that need to work with string contents (e.g., find, toUpperCase, etc.) should in general accept any input ranges whose elements are convertible in some way to dchar. Some of these functions may require forward ranges or bidirectional / random-access ranges. Most of these functions can allow infinite ranges (so we only need the occasional !isInfinite check). (2) Functions that don't need to work with string contents, i.e., the strings are treated as opaque blobs to be passed to, say, an underlying OS function, require finite ranges, but should be able to work with any type that converts to string in one form or another. So anything from (finite) ranges of char-like elements to aggregates with alias this to string ought to be accepted. They can be internally converted to strings if necessary (e.g., to pass to an OS call). I suspect that many of the functions in category (1) can be coalesced with generic range algorithms, so they should not even be exposing their sig constraints in the public API. Instead, they should take a generic range and then use static if or module-private helper functions to dispatch to the right implementation(s). Category (2) functions can internally call helpers (maybe in std.string or std.array) that convert any incoming type that can be converted to string in some way. As for static arrays, I think the consensus is (was?) that they are not ranges, and so the user is required to take a slice before handing it to a Phobos function expecting string or string-like arguments. Well, actually, not just string-like things, but anything to do with ranges. I don't think there's a need to treat static arrays of char separately from static arrays in general. T -- Bare foot: (n.) A device for locating thumb tacks on the floor.
