Scope of temporaries as function arguments

[Maxim Fomin]

On Friday, 28 June 2013 at 16:57:29 UTC, monarch_dodra wrote:
> On Friday, 28 June 2013 at 16:50:07 UTC, Maxim Fomin wrote:
>> On Friday, 28 June 2013 at 16:01:05 UTC, monarch_dodra wrote:
>>>
>>> I thought that was where you were getting to. Couldn't this 
>>> simply be solved by having the *caller*, destroy the object 
>>> that was postblitted into foo? Since foo ends up not being 
>>> called (because of the exception), then I see no problem 
>>> having the caller destroy the "to-be-passed-but-ends-up-not" 
>>> object?
>>
>> In case when there is no exception, struct argument is passed 
>> and is modified in callee, destructor in caller would have 
>> unchanged version (because structs are passed by value).
>
> I'm saying the "callee" destroys whatever is passed to it, all 
> the time, but that means "callee" needs to actually be called.
>
> If "caller" constructs objects, but then fails to actually call 
> "callee", then caller *has* to be responsible for destroying 
> the objects it has built, but not passed to anyone. But this is 
> only if an exception is thrown:
>
> No exception:
>   Caller constructs objects into foo.
>   foo is called, foo becomes owner of objects.
>   foo finishes.
>   foo destroys object.
>
> Exception:
>   Caller starts construction.
>   Exception is thrown.
>   Caller destroys objects as exception is propagating.
>   All objects are destroyed, exception goes up.

In this scenario caller should distinguish between two 
situations: exception was thrown during arguments evaluation or 
was thrown somewhere in foo, when callee can call destructor for 
passed argument. Otherwise (for example, using current 
scope(failure) mechanism to tackle the problem), destructor would 
be called twice on same struct - first time inside callee as 
usual, second time - in caller which would think that exception 
was thrown during argument evaluation. I think some tweak 
required here, but this sound like a good solution.