Re: Problems with PR 21210

[Mark Mitchell <mark at codesourcery dot com>]

Benjamin Kosnik wrote:
> > or that it leaves other 
> > problems open in general, with respect to C99 complex vs. C++ complex?
>
> You're solving this issue just for std::complex. Admittedly the problem
> domain may be small for this issue (although I suspect scientific
> computing types would disagree). A solution may be useful for
> more than just std::complex.

I *am* a scientific computing type. :-)

I'm not sure what other areas of concern arise, with respect to this PR, 
which is just about the core language.

There are indeed other questions, though, like:

1. Overload resolution

  void f(std::complex<double>);
  void f(__complex__ double);

  double d;
  ... f(d) ...

which f should get called?  Under the semantics I used (conversion from 
double to __complex__ double is a standard conversion) we'd pick the 
second "f".  I'd say either we should use the second "f", which seems 
right to me; the other plausible choice would be to consider the call 
ambiguous.

2. Should we have overloads of "sin" (and so forth) for "__complex__" types?

But, those other questions seem outside the scope of the original PR 
(which is about a core language problem) although clearly within the 
scope of the general question "how do we integrate C99's complex types 
into C++?"

The problem I'm faciing is that the PR is about a core language (not 
library) problem; however, the obvious core language fix breaks the 
library.  I'm hoping Gaby's going to ride up on a white horse with some 
kind of consensus of C++ standards committee people...

> What happens if other C99 or C0x types are added (ie ucs2 integer
> type)? I think figuring out a way to deal with this now in the general
> case is probably a better idea.

I don't think we can come up with a general method.  Each C99/C0X type 
is going to interact differently with different parts of the language 
and the standard library.

I agree that the constructor thing is a hack.  But, if Gaby's horse 
doesn't make it, I think it should be considered seriously, in view of 
the fact that the other good suggestion is a change to the core overload 
resolution rules, which is rather more irreversible.  In other words, 
the constructors in the library would be at worst redundant, but could 
be safely left in forevermore; the core language change might result in 
incompatible changes to G++ in future.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304