Re: Problems with PR 21210

[Paolo Carlini <pcarlini at suse dot de>]

Mark Mitchell wrote:

>> 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.

Ok, I see.

>> 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.)

Definitely it would.

>> 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.

Yes, I figured out that point was not 100% clear in my reply two seconds
too late. In my opinion, given the *current* status of C++ vs C99, it
makes a lot of sense actually *preferring* the conversion to double.
More generally, makes a lot of sense "isolating" the __complex__
extension as much as possible fromt the rest of C++ (see also the
overloading issue).

> But, I do think Jason's proposal is technically viable, even if it's
> not my first choice.

Ok ;)

>> 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__)...
>
> More generally, if Jason proposal is considered too risky a choice from
>
> 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.

At least for 4.0.x, I would be *strongly* in favour of that, if you ask
me. People cannot use anymore vectors of __complex__, this is an hard fact.

Paolo.

>
>