list literal gotcha and suggestion

[Neal Gafter]

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