When should value parameters be destroyed?

[Jason Merrill]

Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:

> > Of course, the compiler could *still* invoke the destructor in the
> > callee under the as-if-rule, provided the access check occurs in the
> > caller.
> 
> But the access check is compile-time, right?  There's nothing to
> prevent a compiler from doing it at the call, but still calling the
> parameter destructor in the callee (without checking), right?

Right.  And there is precedent for this in the handling of access
control for operator delete when the deleted object has a virtual
destructor: we check access to op delete at the site of the delete
expression even though the actual deletion will be done from the
destructor.

> Nevertheless:
> 
> > That gets tricky since there are other conditions as well, e.g. that
> > destruction must occur outside a function-try-block of the callee - so
> > I'm in favour of having the caller destroy the object.
> 
> This seems important to me.  One could still, I suppose, call the
> destructor in the callee, but outside its try-block if any.  But this
> gets to be a complicated implementation, and I don't think we want to
> require this treatment.

It's really not complicated at all.  In gcc, the parms just live in
the outermost (implicit) scope; the function-try-block is inside that
scope, and everything is handled by the same code that deals with
user-written blocks.

> The ABI must choose one approach, so I guess I'm now convinced it
> should be to invoke the destructor in the caller.  Anyone else have
> issues to raise before I make that explicit?

I would prefer not to, given the space advantage of the current
strategy, but I'm willing to go along if others feel that this is the
best way to go.

Jason