Proposal for std.path replacement

[Graham St Jack]

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.

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?

-- 
Graham St Jack