------- Comment #26 from mark at codesourcery dot com 2008-01-07 01:16 ------- 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 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 It isn't different to the user. This isn't quite the same situation as fixing an accepts-invalid bug in the front end. There, a user had no reason at all to expect the code to be valid, and the only way to make the compiler conform to the requirement to emit a diagnostic is to reject the code -- or at least give a warning about it. And I'd prefer to warn rather than error where practical. Imagine that you're a user. You read about GNU __complex__ types in the manual. You write some code with them. Then, you want to call some C++ functions that expect std::complex. You look at the libstdc++ source code, notice a constructor there that does what you want, and use it. You upgrade to a new version of G++ and your code breaks. I'm sure you agree that this doesn't make you happy. So, let's not try to argue that changing the constructor signature is painless. Instead, let's decide whether that's a better or worse solution than adding more constructors. As I said previously, if adding more constructors is going to break something, then I agree that it's bad. > 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 don't understand this argument. Do you mean a future addition to the ISO C++ standard or to the GNU C++ library? We control the latter, so that doesn't seem like a problem. Is it conceivable that ISO C++ will ever add a complex<double>::complex(int) constructor that doesn't set the real part to the value of the argument (converted to double), and the imaginary part to zero? I'm not involved in the standards process at this point, but that would be amazing to me, both since that would change the meaning of: complex<double>(3) and since it would not conform to the usual mathematical notions of projections of integers onto the complex plane. What is the concern that you have? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
