Re: A suggestion for resource management

[Florian Weimer <fw@deneb.enyo.de>]

* Niklas Holsti:

>> In a sense, it's just repeating what Unchecked_Deallaction does behind
>> the scenes.
>
> I don't understand your comment at all. An instance of
> Unchecked_Deallocation is explicitly executed where it is called, not
> at some later point in time, and no pragma is involved. Or do you mean
> Finalize for controlled types?

Exactly, Unchecked_Deallocation arranges for calls to a somewhat
non-obvious set of Finalize subprogramms.

> However, if the evaluate-and-save is *only* equivalent to renaming,
> you can get weird effects where a scalar variable seems to have
> different values at different places in the parameter list. For
> example, consider (using the pragma syntax):

Oh, so scalars need to be copied after all. 8-)

> Moreover, what happens if an actual parameter is a function call?
> Should the function be called at the point of the "pragma Scoped", or
> later?

At the point of the pragma.

> I think the clearest solution to point (4) is to say that all of the
> "scheduled" code is evaluated and executed later (before the "end").

>> The branches of an if statement aren't a
>> handled_sequence_of_statements, so it's not allowed.
>
> Ok, I misunderstood your suggestion: you would only allow pragma
> Scoped on the "top" level in a handled_sequence_of_statements.
>
> But why make this limitation? It seems to me not unlikely that some
> application may conditionally Open a COBOL_File, and then a similarly
> conditional Close should occur at the end. One could even let "pragma
> Scoped" be used in loops and execute the clean-up code just before the
> present iteration of the loop ends.

There is an ambiguity whether the cleanup will occur at the end of the
sequence_of_statements, or at the end of some outer scope.  As a case
in point, in the "if" case, you suggest to prefer outer scope, but for
the loop case, you want local cleanup.  I couldn't decide which one is
the right approach, so I made both illegal.

>> I'm not sure if it still can
>> be considered good language design.  Most languages which strive for
>> exception safety are gradually moving to different constructs (even
>> Java).
>
> That could be an argument. Can you present these "different
> constructs" here as examples that we could compare to "finally" and to
> your proposal?

Python:

  <http://docs.python.org/reference/compound_stmts.html#with>
  <http://www.python.org/dev/peps/pep-0343/>

Java:

  <http://blogs.sun.com/darcy/entry/project_coin_updated_arm_spec>

C# (which contained it from the start):

  <http://msdn.microsoft.com/en-us/library/yh598w02%28VS.80%29.aspx>

Go (with some peculiar semantics):

  <http://blog.golang.org/2010/08/defer-panic-and-recover.html>
  <http://golang.org/doc/go_spec.html#Handling_panics>

Perl 6 apparently has LEAVE (as a more dynamic variant of END), but I
don't know if it is actually used.

For evidence that try-finally doesn't work, it's instructive to run a
suitable static analyzer on a code base for the first time.  Even if
the developers are competent, you'll find rule violations, several of
them caused by a desire to reduce syntactic overhead.