🚀 go-pugleaf

The following produced interesting results on several compilers.  I am not
using the compilers to interpret the DWP, but am trying to use the DWP to
justify the compilers and predict the future.  None of these compilers
support the four new specific casts; however, I will try to explain their
actions in terms of them.  The question involves the first item following
return in fun.  I believe the += disambiguates to an expression statement.

struct I1 {
	I1 (int v) : x(v) { }
	I1& operator+= (const I1& rhs) { x += rhs.x; return *this; }
	int x;
	};
struct I2 {
	I2 (int v) : x(v) { }
	I2 (const I2& src) : x(src.x) { }
	I2& operator+= (const I2& rhs) { x += rhs.x; return *this; }
	int x;
	};
int nofun (const int& s) { return (int&)(s) += 10; }
int fun (const int& s) { return int(s) += 10; }
I1 fun (const I1& s) { I1 t(10); return I1(s) += t; }
I2 fun (const I2& s) { I2 t(10); return I2(s) += t; }

		  comp1            comp2            comp3            comp4
nofun     const_cast<int&> const_cast<int&> const_cast<int&> const_cast<int&>

fun(int)  const_cast<int&> static_cast<int> static_cast<int> static_cast<int>
          *****            error lvalue     error lvalue     error lvalue
fun(I1)   static_cast<I1>  const_cast<I1&>  static_cast<I1>  static_cast<I1>
          no error         *****            no error         error lvalue
fun(I2)   static_cast<I2>  static_cast<I2>  static_cast<I2>  static_cast<I2>
		  no error         no error         no error         no error

When I originally wrote fun, my intent was to create an unnamed temp and
return a modification of it.  This requires the use of a copy constructor
and I was surprised to find that I got different results when I wrote it
and when I let the compiler implicitly provide it.  fun(I2) gave me what
I wanted and has been permitted by many compilers.  If I read the DWP
correctly, constructors return rvalues and it is now illegal.  That's
fine with me.  In the future, if a compiler accepts fun(I2) it will not
be certified.  Or did I miss some other interpretation which would allow
fun(I2)?

Assuming that fun(I2) is not legal as a static_cast, is there any way to
justify the two compilers which interpreted similar expressions as
const_cast?  If so, a DWP compliant compiler would also be allowed
(required?) to use const_cast in fun(I2).  I usually assume that a
compiler will do what I tell it with references; whenever I could do it
with pointers.  All of the compilers above worked as expected with
nofun(int).  None of them would allow what the two seem to be doing.
Changing to pointers, I tried *&(I1)*s and was told that I could not
use & with an rvalue.  They also rejected (I1)*s.  Good.  I do not assume
that a compiler will only do with references what I could do with pointers.
Does the compiler have enough freedom to place its implicit dereference of
the lvalue (bad words, hear the thought) into the cast to produce a valid
const_cast?  I hope not.

I also tried to turn fun(I1) into the same results as fun(I2) by placing
an explicit use of the copy constructor prior to the cast.  Now the
compiler must implicitly generate it.  That did not change anything.
Does the DWP require the compiler to "remember" that it implicitly
generated something?  Does an explicitly written copy constructor with
the same semantics as the implicit one have different meaning?

Thanks,
John
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]