Proposal for std.path replacement

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Fri Mar 4 00:15:54 PST 2011


On Fri, 04 Mar 2011 13:53:33 +1030, Graham St Jack wrote:

> On 04/03/11 12:34, Bekenn wrote:
>> On 3/3/11 3:30 PM, Graham St Jack wrote:
>>> My first instinct would be to use non-templated functions that take
>>> const
>>> char[].
>>>
>>>
>> Please don't ever restrict encodings like that.  As much as possible,
>> libraries should seek to be encoding agnostic (though I'm all for
>> const-qualifying parameters).  This is one area where I feel the
>> standard library severely lacks at present.
>>
>> As a Windows developer, I prefer to use wchar strings by default and
>> use only the W versions of the Windows API functions, because the A
>> versions severely limit functionality.  Only the W versions have full
>> support for Unicode; the A versions are entirely dependent on the
>> current (8-bit) code page.  This means no support for UNC paths or
>> paths longer than 260 characters, and also means that international
>> characters commonly end up completely garbled.  Good practice in
>> Windows is to consider the A versions deprecated and avoid them like
>> the plague.
> 
> Ok, I don't mind supporting wchar and dchar in addition to char,
> especially if Windows insists on using them.
> 
> My main issue here is with the constness of the parameters. I think the
> correct parameter to pass is const C[]. This has the advantages of: *
> Accepting both mutable and immutable data. * Declares that the function
> won't mutate the data. * Declares that the function doesn't expect the
> data to be immutable.

The problem is that the functions return slices of their input argument, 
which means that the constancy of the input argument gets transferred to 
the return value.  Here's an example to illustrate:

    C[] first(C)(const C[] s) { return s[0 .. 1]; }

    char[] a = "hello".dup;
    auto b = first(a);

Try to compile this, and you get the error message

    Error: cannot implicitly convert expression (s[0u..1u])
    of type const(char[]) to char[]

The correct thing to do is to use inout, like this:

    inout(C)[] basename(C)(inout(C)[] path) { ... }

I templated the functions on character type rather than string type 
exactly because I plan to do this.  Unfortunately, it's not possible at 
the moment, because inout isn't properly implemented yet:

    http://d.puremagic.com/issues/show_bug.cgi?id=3748

Note that the functions which do not return slices of their input, such 
as setExtension(), joinPath(), etc., all have input parameters that are 
properly marked with 'in'.

> It would be even better to use const scope char[], declaring that a
> reference won't be kept, but it seems that scope in this context is
> deprecated.
> 
> Once upon a time "in" meant const scope. Does anyone know what it means
> now?

Still does.

-Lars


More information about the Digitalmars-d mailing list