Proposal for std.path replacement

[spir]

On 03/04/2011 04:23 AM, 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.
>
> 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?

AFAIK not only 'in' is still const scope, but it precisely means what your 
param is: plain input.
(I would love params to be 'ini' by default.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com