list literal gotcha and suggestion

Reinier Zwitserloot reinier at
Wed Oct 7 04:33:16 PDT 2009

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()  

  --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 
> > 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 
>> > 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

More information about the coin-dev mailing list