Problems with PR 21210

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| > | 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.
| 
| You can't initialize an array at present in this way, e.g.:

    struct S {
       double data[2];
       S() : data()             // #1
       { }
    };

At line #1, we have value-initialization.  Are you disagreeing with that?

|    typedef int IA[2];
|    void f() {
|      IA(); // Invalid

yes, but consider that S() -- with above definition of S -- triggers
value initialization.

|    }
| 
| I think that what you're really doing is reinventing Nathan Myers'
| idea, but making _Complex a separate type from std::complex.  You're
| saying that it's like an aggregate, not a scalar, but has overloaded
| operators (like "+"), that it permits explicit conversions from
| integers, but not implicit ones (as if it had an "explicit"
| constructor),

as if written as

     doubel ary[2] = { x };

| and that it can be constructed with "fcomplex()" (as if
| it had a default constructor), but that this is not
| zero-initialization.  

I did specfically said "value-initialization".  Are you claiming that
value-initialization does not exist for aggregates?

It would help a lot that people do actually read what is written
before characteriing them.  In this discussion, I had to point out 
the micharacterizations nearly every mail :-(

| I just wanted to fix a PR that affected 4.0.  

Me too, for the record...

-- Gaby