core.sys.windows.windows and TCHAR

[Regan Heath]

On Fri, 10 Jan 2014 00:37:06 -0000, Adam D. Ruppe  
<destructionator at gmail.com> wrote:

> Can we change this to alias wchar instead of char? While this would be a  
> breaking change, the ASCII Windows functions are arguably always wrong  
> to use with D since a D char* is NOT an ascii nor Windows encoded  
> string, so any code it "breaks" was already (perhaps) broken and should  
> be changed anyway.

IIRC wchar_t is actually UCS-2 (called Multibyte by devenv and various  
functions) which is a sub-set of UTF-16.  So, calling a windows W function  
with wchar[] could also break.. just in far fewer cases than char[] with A  
functions.

> I know there's other win32 bindings we can download, but for just the  
> common types, I like to use the built in aliases, and TCHAR, TSTR, etc.,  
> are common in copy/pasted MSDN code and can easily be subtly wrong with  
> this.
>
> A compromise I'd accept is putting the wchar aliases under a  
> version(Unicode) so it is opt-in.

As far as I am aware there is no good reason to prefer the ascii functions  
over the multibyte ones.  So, I think defaulting to multibyte is a  
reasonable decision.

Having a way to opt back into ascii would be desirable in some cases  
though.  So, I think we want both sets of aliases in version blocks (Ascii  
and Multibyte) and we actually want the compiler to define the default of  
Multibyte which would be overridden by version=Ascii on the command line.

Remind me, cos I haven't looked in ages.  Do we define prototypes for both  
the A and W versions of functions outside of version() blocks?

Then use version blocks to alias either the W or A to a name without  
either? (in the same way the windows headers do)

Regan

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/