Taking the address of an rvalue struct

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s

> > I think invoking methods on rvalue structs needs to be allowed come Hell or high
> > water.  What's wrong with just banning any optimization of rvalue structs that
> > have methods called on them, i.e. requiring the compiler to treat them the same as
> > named methods, allocate stack space for them that doesn't get reused elsewhere in
> > the same function, etc.?
> Prolonging the lifetime of temporaries to the end of the enclosing
> function would be interesting, but perhaps surprising. Not to mention
> inefficient.

Well, it's slightly mitigated by only needing to prolong to the end of the
enclosing scope.  That said, I forgot about the extent to which destructors
complicate things.  I was thinking that the worst that happens by prolonging the
lifetime is you waste a little extra stack space.  If it weren't for the desire to
avoid ridiculously complicated rules with exception after exception, I'd say that
the lifetime should be prolonged iff there's no d'tor.

That said, I still think that calling methods on rvalues needs to be preserved
come Hell or high water.  I'd rather have the weird corner cases happen when
someone takes the address of a this reference (relatively uncommon) than when
someone tries to, e.g. add two rvalue BigInts (common).  For example:

auto num = BigInt(2) + BigInt(3);

The bottom line here is that there is no non-surprising behavior, at least that I
can think of.  Disallowing rvalue method calls will surprise a lot of ppl w.r.t.
operator overloading.  Prolonging lifetimes will surprise a lot of ppl w.r.t. when
d'tors get called.  The status quo will surprise a lot of ppl w.r.t. undefined
behavior when they take the address of the this reference on an rvalue.