From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7fcf9180e7ba7ab1 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder.news-service.com!feeder.news-service.com!tudelft.nl!txtfeed1.tudelft.nl!news.buerger.net!LF.net!news.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: A suggestion for resource management Date: Sun, 22 Aug 2010 17:29:54 +0200 Message-ID: <87occuhdhp.fsf@mid.deneb.enyo.de> References: <8762z4gcoi.fsf@mid.deneb.enyo.de> <8darikF1b0U1@mid.individual.net> <87eidr3cje.fsf@mid.deneb.enyo.de> <8dcdu1F4v9U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: idssi.enyo.de 1282490994 28887 172.17.135.6 (22 Aug 2010 15:29:54 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:bjJ9SG+EtyMeX2FXPVZu08JYc1w= Xref: g2news1.google.com comp.lang.ada:13612 Date: 2010-08-22T17:29:54+02:00 List-Id: * 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: Java: C# (which contained it from the start): Go (with some peculiar semantics): 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.