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