Re: Problems with PR 21210

["Nathan (Jasper) Myers" <ncm at codesourcery dot com>]

On Wed, Jun 01, 2005 at 07:26:28PM +0200, Gabriel Dos Reis wrote:
> "Nathan (Jasper) Myers" <ncm@codesourcery.com> writes:
> 
> | >     void f(const complex<long double>&);  // #1
> | >     void f(double);                       // #2
> | >     int main() { std::complex<double> z; f(z); }
> | > 
> | > Currently, this will pick #1.  
> | 
> | We don't have any choice but to do something that most people would
> | consider broken, one way or another.
> 
> Yet, a change that silently breaks the above does not read sensible 
> to me.

Not to me, either.  I would not suggest any change that could break 
existing, conforming C++ programs.  

> | 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.
> 
> We're considering extensions here that shold help us implement the
> library efficiently.  I do not consider breaking existing programs
> with well-defined semantics, because of clear semantics, something
> that  we should seriously contemplate.  The chances that such a
> change would get into C++0x appear very low to me.

Of course.  But this isn't about efficiency.

Programs that mix C99 and C++ are not considered to have "well-defined 
semantics" (yet).  Right?

> | 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.  
> 
> Without changing the conversion rule, one runs into ambiguity.  We can
> do the small change of making the conversion scalara -> __complex__
> explicit in C++.

Eliminating various C99 implicit conversions must figure prominently 
in any solution, regardless of how std::complex and _Complex end up 
related, or not.

> | 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.
> 
> However, we must be very careful.  The primary reason why we have
> three specializations is that conversion between std::complex is
> implicit for value/precision preserving conversion, whereas
> value/precision dropping conversions are made explicit -- contrary to
> C99.  C++ codes have been written against such semantics.  We must not
> break them.  As you said earlier, as close as possible to C99, but not
> closer. 
>
> __complex__ is useful and implementation detials, but we need not
> complicate things for its sole support.  If the view is that it is
> close to std::complex, then we must make it an aggregate and must be
> careful about throwing in implicit conversions.

I don't view it as an implementation detail.  I view it as a C99/C++
integration issue.  Users expect mixing them to work with unsurprising
results.  Performance improvements, if any, are absolutely incidental.

Nathan Myers
ncm@codesourcery.com