Specification amendment

B. Blaser bsrbnd at gmail.com
Fri Dec 27 15:41:28 UTC 2019


All right, no problem (this was mostly a suggestion and I'm rather busy too).

Note that currently the same example involving capture conversion
works perfectly:

class Test4<T> {
    interface I<V> {}

    <W, X extends I<W>> X m() { return null; }

    void n(I<Integer> p) {}
    void o(I<T> p) {}

    void run() {
        Test4<? extends Integer> that = null;

        n(m());
        that.o(m());
    }
}

Ciao,
Bernard

On Sun, 22 Dec 2019 at 22:14, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> 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


More information about the compiler-dev mailing list