syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[H. S. Teoh via Digitalmars-d]

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.