Proposal for std.path replacement

[Jonathan M Davis]

On Friday 04 March 2011 00:25:31 spir wrote:
> 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 ---------------------^

That's now how D works. That's not how it well ever work. Every time such an 
idea hos been brought up to Walter (and probably any of the major developers for 
that matter), it has been shot down. It's too big a departure from C, C++, Java, 
C#, etc. And the benefit is seriously questionable anyway. All it means is that 
instead of marking stuff as const or in a decent chunk of the time, you're going 
to have to mark stuff as mutable a decent chunk of the time - possibly more. It 
would confuse most programmers to no benefit. You'd just be trading a common, 
known default to a uncommon, strange one (for C-based languages anyway) and 
changing which variables you had to mark with what. You're still going to have 
to mark plenty of variables as something other the default.

So, no. in will never be the default.

- Jonathan M Davis

- Jonathan M Davis