Proposal for std.path replacement

[spir]

On 03/04/2011 07:17 AM, Jonathan M Davis wrote:
> On Thursday 03 March 2011 19:23:33 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?
>
> That's still what it means. scope in this context is _not_ deprecated. Only
> scoped local variables (not scoped parameters or scope statements) are
> deprecated. in would be the correct thing to use. It's used elswhere with
> strings is Phobos. And yes, as long as the strings being passed in are not being
> mutated, then having the parameters be in is the correct thing to do.

What about 'in' as default? I think a function changing its params is a special 
case --and somewhat unsafe-- which should be clearly indicated at the interface 
level.
	void decode (S,T) (S source, mutable T target) {...}
unchanged ---------------------^

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