Notes on implementing concise calls to constructors with type parameters

[Joseph D. Darcy]

Hello.

Especially given the tricky nature of the type system, being able to 
play with Maurizio's prototype implementation of the diamond operator 
will be extremely helpful and informative.  I think Maurizio's approach 
provides a favorable migration path and is worth further exploration.  
We generally don't want large changes to inference in the compiler or 
language in JDK 7 and the small size of Maurizio's patch is encouraging 
on that front too.

-Joe


Neal Gafter wrote:
> On Thu, May 14, 2009 at 4:28 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
>
>   
>>  Yes, assuming the "diamond" construct is only to be used on the
>>     
>>> right-hand-side of an assignment.  But I think it's wrong to make language
>>> constructs non-orthogonal.
>>>
>>>       
>> It seems to me that the "diamond" construct has always had this
>> restricted-ness right from the beginning. See the original draft:
>>
>> http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000009.html
>>
>>     
>
> Noted.  That's why I got involved - to get this corrected by designing the
> construct to be orthogonal to assignment.  Your approach isn't an
> implementation of this specification - not even close.
>
>  Btw - allowing inference in method invocation context is rather complex - a
>   
>> slight variation of your example fails to compile with both approaches;
>> given the following  method declaration:*
>>     
>
>
> Saying it fails and saying it is complex are two different things.  Yes, it
> fails just as it would using static factories, and for exactly the same
> reason.  It's because the specification is so *simple* by relying on the
> existing inference algorithm.  I'm not suggesting that change until and
> unless it changes for type inference on ordinary method invocations as
> well.  Another advantage of my proposed approach is that "fixing" type
> inference for other contexts, as I believe we are likely to do later, would
> automatically fix the diamond operator for those contexts as well without
> any additional specification effort.
>
>
>   
>> The bottom-line is: if we just consider inference in assignment context
>> (and I think we should - at least if we want to keep this change 'small'
>>  ;-) ), there's no substantial difference between my proposal and yours.
>>     
>
>
> Inferring type arguments based on the type of value parameters *is *a
> substantial difference.  Keeping the spec small is an admirable goal (it
> isn't clear that your approach would result in a smaller spec), but it
> shouldn't be done at the cost of internal language consistency.
>
> Given that neither approach has even a draft specification, perhaps they
> should be considered out of scope for project coin.
>
>