ARM Blocks: ease of use and for loops

[Neal Gafter]

On Wed, Oct 21, 2009 at 8:39 AM, Joshua Bloch <jjb at google.com> wrote:

> I agree that this would be the right way to do it, but I'm not convinced
> that it meets the bar for inclusion.  It's not a now-or-never thing: its and
> independent change to for-each.


Unfortunately, the shape of the language will affect the shape of libraries
to come, and delaying this aspect of support for Closeable will push
libraries in a less-than-optimal direction.  It is better to add support for
Closeable all at once (or not at all).


>  Two questions come to mind:
> (1)  How big a win would this be in terms of expressiveness?  How often (in
> a real code corpus) would it be applicable. How much nicer would the code
> corpus be with this feature.  Or is it too magic?  (Shorter isn't always
> better.)
>

In C#, the facility is used frequently.  Doing it "by hand" has all the
disadvantages of boilerplate that both statement forms were meant to
eliminate.

Going back to a recurring theme: the present design (without supporting the
for-each loop) fails to consider future evolution of the language.  For
example, we'd regret not doing this now if we add support for iterator (or
asynchronous) methods in the future.

(2) Are there any dangers associated with it?  Suppose an existing final
> class were retrofitted so that its iterator method returned a closeable
> iterator. Then we'd be changing the semantics of an existing for-each over
> that resource.  Is that a problem?
>

As explained before, it isn't a problem, primarily because the existence of
such code, in conjunction with its use in a for-each loop, represents a
resource leak in existing code.  I believe you'd be hard pressed to find in
production use a single example of the kind of code whose behavior would be
changed.