Re: Problems with PR 21210

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| PR 21210 is a complaint that G++ 4.0 has stopped allowing conversions
| from integers to "__complex__ float".  This is a perfectly reasonable
| complaint, as in C99 such conversions are permitted, so if we are
| going to support __complex__ in C++ we should have the same semantics.
| Besides the breakage noted in the PR, other things that do not work --
| but should -- are pseudo-destrutors for __complex__ types and implicit
| conversions from __complex__ types to their real-subparts, as these
| conversions are permitted in C99.
|   
| The right fix, from a C++ language point of view, is to treat
| conversions to __complex__ types from other types as standard
| conversions, if the conversion could be made to the type used for the
| components of the complex type.  Furthermore, __complex__ types should
| be treated as "arithmetic" types.
| 
| All that works just fine -- except that we run into problems with:
| 
|   complex<double> d(3);
| 
| The libstdc++ std::complex templates contain a non-standard
| constructor:
| 
|       complex(__complex__ double);
| 
| in addition to the standard:
| 
|       complex(double = 0.0, double = 0.0);
| 
| So, we get an overload ambiguity; converting to double is no better
| than converting to __complex__ double.
| 
| I really don't like the idea of creating a new class of conversions
| that is worse than a standard conversion, but better than a
| user-defined conversion, for interactions with complex types.  From a
| language-design point of view, we really should be treating
| __complex__ types as an "arithmetic" type.

Agreed.

| Removing the extra libstdc++ constructor is not ideal, because then
| __complex__ double can still be converted to complex<double> -- but
| the conversion happens via the implicit conversion from __complex__
| double to double, so the imaginary part of the value is lost.
| 
| So, I think that what we should do is add constructors.  For example,
| for double, we would add:
| 
|   complex(int);
|   complex(long);
|   complex(long long):
|   complex(unsigned int);
|   complex(unsigned long);
|   complex(unsigned long long);
|   complex(long double);
| 
| (We don't need bool, char, short, or float because they will promote
| to one of the other types, and promotions are better conversions than
| standard conversions, so there's no ambiguity.)
| 
| I can't see how adding these constructors will break anything,
| relative to the standard, in that all of these conversions were
| already permitted, but it's definitely possible I'm overlooking
| something.
| 
| I've attached the draft patch I've been using for the front end, but
| before I start making library changes I'd like to get some buy-in from
| the V3 deveopers.

Thanks.  Please could you allow for a day or two?

-- Gaby