Problems with PR 21210

[Mark Mitchell]

Paolo Carlini wrote:
> Mark Mitchell wrote:
> 
> 
>>The conversion to "S" requires a constructor call, which is usually
>>considered worse than a "standard conversion" (like converting from
>>"int" to "double").  So, that's why I think we should call the second "f".
> 
> 
> Well, you carefully avoided to tell me, but currently we *are* calling
> the *first* "f"... ;)

That's true.  That's because, at present, we don't allow any implicit 
conversions to/from __complex__ types, at variance with C99.

> This doesn't mean I'm not seeing your point of course, but maybe we
> don't really want to have the "right" overloading *now*, when things are
> still up in the air about C++ vs C99...

Sure, we could just wait until this is completely solved in the 
committee.  (In fact, we could even turn off __complex__ in C++ until 
then.  I'd be OK with that, but it would break more things for people 
who are using __complex__, including V3.)

> this context, Jason proposal seems naively right to me, in the sense
> that seems to me "conservative": given the *current* standard how
> possibly an extension like __complex__ can be preferred to a builtin type?

I'm confused; I don't think any proposal is preferring __complex__ to a 
builtin type.  My proposal made a conversion from "int" to "__complex__" 
equivalent to a conversion from "int" to "double" -- but not better. 
But, I do think Jason's proposal is technically viable, even if it's not 
my first choice.

> More generally, if Jason proposal is considered too risky a choice from
> the point of view of the future evolution of C++, I would suggest to
> stay as close as possible to the behavior of 3.4.x. To my best
> knowledge, not many people complained. I would venture to say, no-one
> complained about the behavior of vector<__complex__> and
> std::complex(__complex__)...

I agree with the spirit of what you're saying, but I'm not sure I know 
how to achieve it in our current codebase.  But, I also haven't looked 
at exactly what 3.4.4 did very closely, and I don't really know if it 
makes sense.  If there's no consensus about how to move forward, we can 
look further into just trying to be bug-compatible with 3.4.4.

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