On Fri, 10 Jan 2014 00:37:06 -0000, Adam D. Ruppe
<destructiona...@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/
