VOTE: What's the future of wxT() and _T()?

[Vadim Zeitlin]

On Fri, 30 Nov 2007 17:38:47 +0100 Anders Larsen <al at alarsen.net> wrote:

AL> On Thu, 29 Nov 2007 00:24:40 +0100, Vadim Zeitlin wrote:
AL> 
AL> >  At this moment I'm really rather inclined to throw a pair of dice instead
AL> > of continuing to thinking further what is the best thing to do :-/
AL> 
AL> Not that I'd attempt to influence your dice, but how about the following?
AL> (this would leave current behaviour unchanged on Windows)
[...patch to change wxT() to do nothing elsewhere but keep it as is
    under Windows snipped...]

 This is yet another appealing but potentially very confusing solution. I
really don't know which one should we choose. All of the following seem to
be acceptable and each has its own advantages and disadvantages:

0. Don't change anything, let wxT() and _T() always generate wide strings.
 + Nothing to do
 - Compatibility problems with existing Unicode code (wxCmdLineEntryDesc)
 - Unnecessary wchar_t->UTF-8 conversions in UTF-8 builds (but removing
   wxT()s completely is not the answer as they avoid the conversion in
   wchar_t builds, i.e. wxMSW)

1. Make wxT() do nothing but keep _T() as it is now
 + Fixes compatibility problems for the code using wxT()
 - While leaving them for the same code using _T()
 - Breaks symmetry (mentioned in hundreds posts in the archives, FAQ
   entries &c) between wxT() and _T()
 - Requires updating the entire code base to get rid of unnecessary
   conversions (in common code wxT/_T will need to be replaced with wxTEXT,
   in wxMSW wxT will need to be replaced with _T and elsewhere they will
   both have to be removed)

2. Make wxT() do nothing in UTF-8 builds, keep it as is under Windows
 +/- Same as above except wxMSW code won't need to be updated any more: but
     at the price of not even fixing wxCmdLineEntryDesc compatibility for
     Windows programs

3. Make both wxT() and _T() do the same thing as wxSTRING_TEXT does
 + No more unnecessary conversions anywhere, without changes to the code
 + Helps with wxCmdLineEntryDesc under Unix
 - But not under Windows

4. Make both wxT() and _T() do nothing
 + Fixes wxCmdLineEntryDesc compatibility problems
 + No more unnecessary conversions under Unix without changes to the code
 - Risks to be a nasty surprise to Windows programmers used to _T()
 - Unnecessary conversions still happen during run-time under Windows


 Having written this the rather obvious best choice to me seems to be (3).
Of course, it still suffers from the problem mentioned by David (as do all
choices except (0)) in that it can break user code passing wxT("foo") to a
function taking "wxChar *" but fixing this should be trivial. Are there any
other hidden problems with this that I'm missing?

 In any case, I feel we need to decide something about it quickly (I still
hope to do 2.9.0 soon and I'd rather do this change before it) so I'd like
to propose an informal (meaning no lynching of the members of electoral
commission (me) if you're unhappy with the vote counting methodology :-)
vote. So if you have an opinion about this, please post in this thread
keeping the "VOTE" in the subject (and please remove it from the subject if
you want to just discuss this further, without voting, e.g. if you see any
[dis]advantages that I missed or missing options on the ballot).

 Personally I vote for 3,0,4,2,1 in this order (with a large gap between 0
and 4).

 Thanks,
VZ