Feedback and comments on ARM proposal - resend

[Neal Gafter]

On Thu, Mar 19, 2009 at 5:55 PM, Joshua Bloch <jjb at google.com> wrote:
>>  I find this comment offensive,
>
> Sorry.  I really did not mean to offend. I do believe that the particular
> case of iterables requiring termination is a red herring.  I know C#
> supports it, but Java went the other way a long time ago. I believe that
> you're the only one who as expressed  enthusiasm for this use case.

The only other person to comment on the issue has been Howard, and I'd
interpret his response as supportive.  In any case, you know quite
well that the quality of a language change can't be measured by the
body count.  Actual experience is required.

> I see
> it as harmful scope creep that could keep a really important facility out of
> the next release.  The proposed construct was designed to address a severe
> problem with existing types.

I understand the urgency you feel around this proposal, given the very
tight time schedule to design it right (1 month), and the very literal
complexity budget that the solution must fall within.  However, a
solution must make sense not just during the transition of existing
code, but it also must fit cleanly into the language after that
transition is complete.  That's what most worries me about this
proposal.  We should not compromise the language based on this imposed
sense of urgency.

> Important or not, it isn't a use case for this construct.  It's specifically
> excluded from this proposal.  I offered to write a proposal for locks, but
> people didn't seem all that interested so I didn't write it.

We all clearly understand that this use case is not well addressed by
the proposal in its current form, and we seem to have some consensus
that a *separate* language construct would not be ideal.  That's why
further work is worthwhile.

>> I'm still hoping to see a revision of the proposal that incorporates
>> the changes you suggested be considered...
>
> In the next couple days.

Excellent.  I'm retrofitting of a bunch of code using the new
construct and, while I don't have a complete compiler for the
construct, I have enough experience using it to raise a few ergonomic
issues in both the syntax and semantics that should be addressed.  I'd
rather report that feedback based on the latest version of the
proposal.