This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with PR 21210


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

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

In my understanding we should do our best to allow people to keep on
using __complex__ together with std::complex in the way they are used to
do. At the same time we should not try too achieve too much *now*. In
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?

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

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]