Specification amendment

[Maurizio Cimadamore]

There's plenty of discussion and contents in this thread. We already 
have a spec bug to track this - let's link the bug to this discussion, 
and I'm sure Dan will look at it when he has some cycles.

Maurizio

On 22/12/2019 12:04, B. Blaser wrote:
> Thanks for the confirmation, Maurizio.
>
> It may be that I would like to write a draft for this amendment to the
> JLS for submission to our spec experts.
> Should I then post it to this mailing-list, file a CSR with the draft
> inlined or do anything else?
>
> Bernard
>
> On Thu, 19 Dec 2019 at 16:37, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
>>
>>> The problem is that when inferring 'n(m())' the bounds 'X <: I(W),
>>> I(Integer)' implies 'W=Integer' per §18.3.1 but with 'o(m())' the
>>> bounds 'X <: I(W), I(? extends Integer)' should probably imply 'W <:
>>> Integer' instead of inferring 'W=Object'.
>>>
>>> So, I did a voodoo cult devoted to inference which ended up with some
>>> black magic on our good old friend 'Types::isSameType', see below.
>>>
>>> While this experiment is somewhat incomplete, both examples 'putAll()'
>>> and 'o(m())' are now working without any 'langtools:tier1' failure.
>>>
>>> What do you think?
>> This extension is, more or less, what I was expecting/suggesting - but I
>> think this is more of a question for our spec experts (there might be
>> subtle reasons as to why this wasn't done already).
>>
>> Maurizio
>>
>>> Bernard