Proposal for std.path replacement

[Bekenn]

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.

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.