list literal gotcha and suggestion

Neal Gafter neal at
Thu Oct 8 13:41:42 PDT 2009

On Thu, Oct 8, 2009 at 10:42 AM, Reinier Zwitserloot <
reinier at> wrote:

> A strange proposal from Neal "we should add closures so we can make
> these changes via API instead of via a language change" Gafter, indeed.

Well, as long as we're stooping to ad-hominem, I should point out that I
wasn't proposing anything.  You said that you don't know how to use a single
syntax for all of these collections without either requiring casts or target
typing, and concluded that it therefore isn't possible[1].  I showed you how
to do it[2], including answering your follow-on questions.  I was doing so
not because I think that is how I believe this feature should be
designed[3].  Nor because I think this feature is even worth having at all.
I did so because the participants in this list have a wide range of
language-design skills, and most probably don't realize how many of your
pronouncements are simply incorrect.

None of this has much to do with the proposal that has already been accepted
(by Joe Darcy, not by you or me), the deliberations of its expert group, its
implementation, or the probability of it being reviewed and checked-in to
the openjdk7 "tl" workspace on schedule, *feature-complete, *in the next 15
days.  I don't see much risk (or "hope" if you prefer) of that happening.


   1. October 6: (Reiner) "We went over this - target typing is asking for
   problems. If you can shed any light on how gets around these
   problems, perhaps we can reconsider it, but if not, I don't see how this
   changes the situation any."
   2. October 6: (Neal) "The same effect can be had without target typing.
   Essentially, one defines the {}-literals in terms of a newly introduced
   type/class, and then define compile-time conversions from that new type to
   each of the types you want it to convert to.  Java's type inference, for
   example (including constructor type inference), can be described this way,
   and that's how it works inside the compiler."
   3. Sep 30: (Neal) "I agree that a solution along these lines [API-based]
   is a better approach for these literals."

More information about the coin-dev mailing list