list literal gotcha and suggestion

Neal Gafter neal at
Tue Oct 6 12:32:20 PDT 2009

On Tue, Oct 6, 2009 at 12:22 PM, Reinier Zwitserloot <
reinier at> wrote:

> What _should_ it print? Nothing - it was a rhetorical question to show that
> the concept is a bad idea. The compiler should refuse to compile it because
> its ambiguous.
> I was the one who suggested that you must assign the literals to a
> variable. I immediately added that I thought this was a horrible plan. If
> you're going to assign to a variable, then there's not much point in
> creating the literals in the first place - if you have a variable reference,
> then writing a bunch of add/put calls is easy. The lack of list/map literals
> is so annoying precisely BECAUSE you usually need to go through declaring a
> variable name for it, even if your list/map is only going to be used in one
> place. Remember that this is all being considered just to allow set
> literals. We've clearly gone mad.

I agree that your suggestion to require assignments is not a good one.
Assignment is not necessary.  The (automatic) conversion could be triggered
any context that triggers the use of conversions, for example when using it
as an argument to a method.

This discussion is starting to move towards the need to cast this literal to
> make the target typing work.

Casting isn't required either.

> Which it really is - there's just no way short of making massive changes to
> java that 1 type can be autoboxed to both List<List<Object>> and
> Map<Integer, String> - this hypothetical initializer type would need to have
> variable length generics in order to make it work: It would have to somehow
> store the notion that this is a list of lists, where each inner list matches
> the type tuple {Integer, String}.

You seem to imagine that the type has to be denotable in java source.  That
is certainly NOT a requirement.

> Is that really going to be the implementation? Seems more likely at this
> point that the compiler will first look at what type is actually required,
> and only then to start checking the structure of the initializer literals to
> attempt to finagle some sort of type out of it.

Not really.  The type of the initializer is "initializer with so-and-so
structure".  Which is either compatible with the target of the conversion or

The suggestion was made in order to simplify syntax. Evidently, Paul and
> possibly Neal seem to think that "(List<>){{1, "One"}, {2, "Two"}})" is
> simpler than "[[1, "One"], [2, "Two"]]".

Not at all.  I believe that the cast would be unnecessary in virtually all
use contexts, just as the cast from "3" to "byte" is unnnecessary in
virtually all use contexts.


More information about the coin-dev mailing list