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