Let's schedule WinAPI ASCII functions for deprecation!

[Dmitry Olshansky]

On 23.05.2012 0:41, Walter Bright wrote:
> On 5/22/2012 11:11 AM, Denis Shelomovskij wrote:
>> Since Win9x isn't supported any more why do we have ASCII WinAPI
>> functions in
>> druntime's core.sys.windows.windows (and, possibly, other places)?
>>
>> Reasons against *A functions:
>> * using of every such function is unsafe (with really seldom
>> exceptions like
>> LoadLibraryA("ntdll")) because inability to encode non-ASCII
>> characters to OEM
>> encoding will almost always give unpredictable results for programmer
>> (simple
>> test: you, reader, what will happen?);
>> * in D it's too easy to make a mistake by passing UTF-8 string pointer
>> to such
>> function because D has no string types other than UTF and elimination
>> of such
>> function is the only solution unless ASCII string type is created
>> * it performs worse because Windows has to convert ASCII string to
>> UTF-16 first
>>
>> And yes, druntime already has encoding bugs because of using such
>> functions.
>
> First off, I agree that druntime and phobos must not use the A functions
> without a very, very good reason.
>

Right.

> Secondly, as a matter of principle, we are not going to fix, improve,
> refactor, or re-engineer the Windows API, nor any other operating system
> API, nor the C Standard Library, no matter how tempting that may be. The
> job of the D interface modules is to simply provide an interface to
> them, as thin and direct as possible, without editorial comment. The
> user can decide what to use or not use from it.
>

Again correct. The trick is that the way *A functions are provided is in 
fact wrong edit! It signatres are basically saying "hello I'm explicit 
Win32 API multi-byte string binding and I accept UTF-8 string " ... WTF?!

The fact that they are horribly outdated is the perfect moment to both 
fix the issue and get rid of junk.

-- 
Dmitry Olshansky