Notes on implementing concise calls to constructors with type parameters

[Neal Gafter]

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.