[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion

[mark at codesourcery dot com]

------- Comment #24 from mark at codesourcery dot com  2008-01-06 21:06 -------
Subject: Re:  [4.2/4.3 regression] ICE with incompatible types
 for ?: with "complex type" conversion

gdr at cs dot tamu dot edu wrote:

> | I'm not sure what you mean by that.  It's a public constructor;
> 
> I mean that it is not a standard constructor, and it is not a
> constructor I documented as a GNU extension.  The fact that it is a
> public constructor is not, by itself, a documentation that it is a
> standard constructor or a constructor that users should use.

But, it's also not documentation that users should *not* use it.  And,
now it's been out there for a long time, so it's quite likely that some
users somewhere *are* using it.  The run-time library has various
extensions to the standard, and the way people use a run-time library is
partly to open its header files and use what they see.  I think we have
to accept that this is indeed an incompatible change and likely to
affect users.

That said, I do think it's reasonable to break backwards compatibility
here if we have no other choice.  Right now, we have this odd wart in
the language with our handling of __complex__ (treating is as a
non-artithmetic type) which causes other problems.  So, it's possible
that we have to choose between making an incompatible change to the
library and leaving the language wart -- and I think we're all agreed
that in that case we'd rather add the dummy parameter you suggest.

But, you've not shown that my suggestion of adding additional
constructors is detectable by users.  If it's not, then that would be a
better solution: it would allow us to avoid the incompatible change to
the library.  Of course, if adding constructors itself breaks
compatibility, then that's a powerful argument against my suggestion.
So far, all you've said is that it makes you nervous.  Does it actually
break something?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780