Problems with PR 21210

[Gabriel Dos Reis]

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?

If we want to treat __complex__ in C++ as a built-in, then we cannot
have it both working as C99 and working as C++ std::complex<T> because
of incompatible requirements.

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?

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 removes the ambiguity one might run into with
std::complex<>. It isn't fully compatible with C99, but we just 
demonstrated that we cannot have full compatibility with C99 in this
regard. 

-- Gaby