Problems with PR 21210

[Nathan (Jasper) Myers]

On Wed, Jun 01, 2005 at 09:37:38AM +0200, Gabriel Dos Reis wrote:
> 
> My earlier comment did not provide an example:
>     void f(const complex<long double>&);  // #1
>     void f(double);                       // #2
>     int main() {
>       std::complex<double> z;
>       f(z);
>     }
> 
> Currently, this will pick #1.  If we make _Complex double and
> std::complex<double> identical, we silently break the program because 
> now we would call #2 (for a standard conversion is better than
> user-defined conversion). 

We don't have any choice but to do something that most people would
consider broken, one way or another.  The best we can do is to choose
something nobody would consider crazy (e.g. discarding imaginary part 
in _Complex -> std::complex<> copies.)  Since we're outside the realm 
of the standard, anything is allowed; within certain limits we can do 
whatever makes sense.  If what we do works out, it could be adopted 
into C++0x.

What limits?  Our goal must have every program that compiles in both 
C99 and C++ mean the same thing.  Not every C99 program need compile 
in C++, but for any given program in C99 that does not compile in C++, 
it should be obvious how to change it to a C99 program that does, and 
means the same thing.  (This is similar to C++ requiring a cast in 
malloc expressions.)  For a trivial example, we need not provide an 
implicit conversion from _Complex to scalar; it's not safe anyway,
and it's easy to express that conversion explicitly in C99.  

Another limit is that some programs that may be construed to make 
sense need not be accepted, where there is any uncertainty about what 
the committee might decide.  We can loosen the rules later to match 
what they choose, as long that doesn't actually change the meaning of 
valid programs.  In practice I think this means we can say some 
constructs are ambiguous that need not be -- again, even some that 
would be valid C99.  

As soon as we can work out a framework for a solution, with the choice
points identified, discussion should include interested ISO committee
members, so we have a chance that what we do will be in C++0x.

If we fail, _Complex and std::complex<> will be unrelated types, and 
it won't matter much what the semantics are -- the only path from one 
to the other would be via the component parts.  (Even then, disallowing 
_Complex -> scalar conversions would probably be necessary.)

Nathan Myers
ncm@codesourcery.com