------- Comment #25 from gdr at cs dot tamu dot edu 2008-01-07 00:38 ------- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with "complex type" conversion
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | 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. I would not bet money that nobody is not using it. However, that somebody is using something specifically non-standard and NOT documented GNU extension. This situatiation is radically very different from the one where the constructor would have been documented as GNU extension -- then we would be stuck with it, and I would have been pressed hard to suggest what I'm suggesting. [...] | But, you've not shown that my suggestion of adding additional | constructors is detectable by users. It is adding more constructors where the standard says none existed. We have no plan of how those new constructors will interact with future new additions. Consequently, I'm very reluctant adding those constructors -- after all, these new single-parameter constructors are being suggested because of an ambiguity caused by adding a single-parameter constructor that did not exist (in the Standard) in the first place. I would not like to continue that road by adding more, just to fix a mess caused by this constructor and the compiler's handling of __complex__. This isn't a case where I'm ready to say `the more the merrier' :-) Adding an additional dummy parameter to the constructor __complex__ significantly reduces (to zero), the risk of conflict with anything unforseen now. I believe that is what we should do. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
