Proposal for std.path replacement

[Jonathan M Davis]

On Thursday 03 March 2011 18:04:11 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.

It's not a bad thing for functions to be templatized on string type. However, I 
would point out that it's fairly common practice to just use string everywhere 
except where you need a string to be a random-access range - in which case you 
used dstring - or where you need to pass a string to a Windows system function, 
in which case you convert it to a wstring or wchar[]. The need to use wstring 
when using Phobos is practically non-existent. Now, if you're frequently calling 
Windows system functions directly, then wstring and wchar[] would be used far 
more frequently, but don't expect Phobos to be using wstring much.

It's likely that more of Phobos will become string-type-agnostic and templatize 
on string type, but there may be functions which aren't simply due to the 
increased complexity or because no one gets around to it with everything else 
that needs doing. The normal string type to use is string, so that's generally 
what is designed for.

> 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.
> 
> References:
> 	http://msdn.microsoft.com/en-us/library/dd317752%28v=VS.85%29.aspx
> 	http://blogs.msdn.com/b/michkap/archive/2006/10/24/867880.aspx
> 	http://blogs.msdn.com/b/michkap/archive/2006/08/22/707665.aspx
> 	http://blogs.msdn.com/b/michkap/archive/2007/05/07/2464778.aspx
> 
> When I first started looking at D, I compiled the win32 example on the D
> web page.  I noticed it used MessageBoxA, so I changed that to
> MessageBoxW.  That generated an error, because nobody had bothered to
> add a MessageBoxW declaration.  That was the very last time I used
> std.c.windows.

If there are key functions like that that you expect to be druntime (in this 
case, it would be core.sys.windows.windows - I believe that std.c is deprecated, 
or at least it's not intended to be used anymore; OS-specific functions like that 
go in core), then open up enhancement requests for them, or they're unlikely to 
be added. I don't believe that anyone is going through the entirety of the 
Windows API (or the Posix API for that matter) and adding all those functions to 
druntime. They generally get added as required by Phobos or other stuff in 
druntime or because someone requests it. Not to mention, you can always use 
github to make the appropriate changes to druntime and create pull request. That 
would likely speed up such improvements.

- Jonathan M Davis