list literal gotcha and suggestion

[Reinier Zwitserloot]

So, when passing {1, 2, 3} to a method that takes 1 Collection, it  
will not, in fact, work without an explicit cast, then. Okay. As I  
said, I think that's quite a serious use case.

Before you suggest that, then, the construct will default to a List -  
I'm not sure that's a good idea. It would be entirely the same as  
Stephen Colebourne's idea of having collection literals be of a to-be- 
created new type that has a toSet() method, except without the need to  
call toSet() in certain circumstances, but with the need to add a cast  
in others. This is piling on rules in the JLS for something that is  
trivially solved with a library (the toSet() method).

A toMap() method would be a bad idea and wouldn't work very well with  
generics, but fortunately, if only list and map literals need to be  
made, there's no syntax issue.

  --Reinier Zwitserloot



On 2009/07/10, at 17:25, Neal Gafter wrote:

> Its type is "and initializer list with so-and-so structure".  Just  
> like the type of "3" is "integer that fits in a byte".  In either  
> case it is a type that you can't designate in the source.  There  
> would be a language requirement that an expression of one of these  
> types must be subject to conversion to some concrete type.  If you  
> immediately toString() it, I would expect to get a compile-time  
> error that it hasn't been converted to a concrete type.  Indeed, if  
> you really just wanted to toString() it, you could indeed cast it to  
> some collection type.  I don't imagine that need would arise very  
> often.
>
> -Neal
>
> On Wed, Oct 7, 2009 at 4:33 AM, Reinier Zwitserloot <reinier at zwitserloot.com 
> > wrote:
> You yourself said this internal type can't ever be seen in java  
> code. Collection is an interface, so what's it going to _be_? A set?  
> A list? A new unspecified implementation of collection that is  
> neither? What if I pass {1, 2, 3, 1} - will the duplicate be  
> removed? What would it toString() to? (HashSet and ArrayList have  
> different toString() implementations).
>
>  --Reinier Zwitserloot
>
>
>
> On 2009/07/10, at 07:20, Neal Gafter wrote:
>
>> If it is "an initializer" that is "compatible" with the  
>> "Collection" argument type, then the "conversion" exists and the  
>> method is a candidate.  If the method is selected as the most  
>> specific one during overload resolution, then the generated code  
>> will "perform the conversion", which essentially means constructing  
>> the collection object.
>>
>> On Tue, Oct 6, 2009 at 7:45 PM, Reinier Zwitserloot <reinier at zwitserloot.com 
>> > wrote:
>> So, passing a {1, 2, 3} literal inline to a method that takes a  
>> Collection will not require a cast?
>>
>> Please explain how that would work.
>>
>>  --Reinier Zwitserloot
>>
>>
>>
>> On 2009/06/10, at 23:52, Neal Gafter wrote:
>>
>>> On Tue, Oct 6, 2009 at 1:48 PM, Reinier Zwitserloot <reinier at zwitserloot.com 
>>> > wrote:
>>> On 2009/06/10, at 21:32, Neal Gafter wrote:
>>> 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.
>>>
>>> Doesn't coin include byte literals?
>>>
>>> Yes.  That has nothing to do with the part of the existing  
>>> language specification that allows "3" to be assigned to a "byte".
>>>
>>> I think you overstate. "Virtually all use contexts"? I'd say that  
>>> methods taking in a java.util.Collection is a pretty big use  
>>> context.
>>>
>>> Agreed, those contexts are included.
>>>
>>> -Neal
>>
>>
>
>