Re: Problems with PR 21210

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| > Mark Mitchell <mark@codesourcery.com> writes:
| > | Gabriel Dos Reis wrote:
| > | > Mark Mitchell <mark@codesourcery.com> writes:
| > | > | PR 21210 is a complaint that G++ 4.0 has stopped allowing
| > | > conversions
| > | > | from integers to "__complex__ float".  This is a perfectly reasonable
| > | > My reading of the PR is a bit different, especially comment #1
| > | >   typedef float __complex__ fcomplex;
| > | >   fcomplex cplx = fcomplex();
| > | > which effectively produces the error
| > | > 21210.C:2: error: invalid cast from type 'int' to type 'float
| > | > __complex__'
| > | > which is at least disturbing, because there is not cast and no int
| > | > here.  Rather, there is a default value fcomplex() being requested and
| > | > copied into another fcomplex.  There is no conversion requested.  That
| > | > appears to me to be entirely isolated from the std::complex<> thingy.
| > | > Why is that observation flawed?
| > | | Because the "T()" syntax means zero-initialization for builtin
| > | types. You will get the same error message if you write "fcomplex(3)".
| > Aha, I see.  Thanks.  But would not that be separate from the
| > std::complex<> issue you raised earlier?
| 
| No.
| 
| The problem is that we have to say how integers convert to __complex_
| types. 

Yes, I do fully agree on that.  What I'm suggesting is that an int is
convertible to a __complex__ T, but the conversion must be requested
explicilty; just like T* -> int exists but must be written explicitly.

| If it's a standard conversion, then without changing the
| overloading rules, conversion from "int" to "double" or to
| "__complex__ double" is equally good.  So, the std::complex
| constructors are ambiguous.

Only if we choose the wrong kind of conversion.  If we make the
conversion explicit, it will not cause any ambiguity.

| > However, if we treat fcomplex() as value-initialization -- because it
| > is more like an array of two floats, than a float --  then we will be
| > value-initializing its components and that would be OK.  Do you agree?
| 
| I think that would be wrong. 

I don't believe so.  Having __complex__ as aggregates, whose value
initialization follows standard rules, i.e. translate to value
initialization fo components solves the issue.  Having the conversion
from integers explicit also prohibits unwarranted ambiguity.

| The fact that a __complex__ types
| happens to have "real" and "imag" operators doesn't make it any less a
| scalar type to me.  In other words, I think what you're proposing is
| technically feasible, but not a good design.  The fact that it's not a
| compound type in C99 is evidence that we should treat it like any
| other built-in type in C++.

But clearly, C++ does think of complex as an aggregate, e.g. compound
type.  If one decides to make __complex__ behaves as std::complex and
yet std::complex is coumpond whereas __complex__ is not, not only it
is not good design but also technically unsound because of the
difference of the rules that govern them. 

| Jason's approach is better; treat it as a built-in, but make
| conversions to it worse than ordinary floating-point types.  I think
| that's somewhat odd, but much less so than making "fcomplex()" result
| in anything other than complex zero.

Once again, you're mischaracterizing what I said.  From what I said is
fcomplex() would  be value-intialization, and since it would be 
treated as an array of two elements, fcomplex() boils down to
value-initialization of its components, and in this case
zero-initialization of the components. Henc fcomplex() is zero. QED.

| > But, the issue of writing fcomplex(3) is still open.  I think such
| > conversion must be allowed only if written explicitly -- i.e. explicit
| > conversion.
| 
| That's at odds with C99, and at odds with ncm's

But __complex__ is already at odd with std::complex semantics.

| __complex__-is-the-same-type-as-std::complex idea.

But that cannot work because of the different semantics I listed
earlier.  If you make __complex__-is-the-same-type-as-std::complex
then you silently break well-formed C++ programs.

-- Gaby