[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    Re: Incoherent invocation type inference?
From:       "B. Blaser" <bsrbnd () gmail ! com>
Date:       2017-10-19 17:37:26
Message-ID: CAEgw74BAwKz6NxDz4mCUhnsAQGP2dQo1BT+6Xjj0Gszm3eX=rA () mail ! gmail ! com
[Download RAW message or body]

On 28 August 2017 at 14:18, Maurizio Cimadamore
<maurizio.cimadamore@oracle.com> wrote:
>
>
> On 25/08/17 08:23, B. Blaser wrote:
>>
>> Maurizio,
>>
>> On 22 January 2017 at 17:26, B. Blaser <bsrbnd@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> 2017-01-19 18:22 GMT+01:00 Maurizio Cimadamore
>>> <maurizio.cimadamore@oracle.com>:
>>>>
>>>> Not sure about your proposed patch.
>>>>
>>>> To me the warning should be a property of the method declaration, not of
>>>> the
>>>> specific inference.
>>>>
>>>> If a method returns a naked type-variable which is not mentioned
>>>> anywhere in
>>>> the method parameter types -> Lint warning (not an unchecked warning -
>>>> just
>>>> an optional Lint one - category TBD).
>>>>
>>>> It's true that, by looking at the callsite, you can also warn for
>>>> clients
>>>> passing 'null' arguments, but the extra benefit is not worth the extra
>>>> complexity IMHO. And, I think this is a problem of bad API, not one of
>>>> bad
>>>> clients. A well-designed API should not have any methods that match the
>>>> criteria stated above - as their behavior would ultimately be at the
>>>> client's mercy.
>>>>
>>>> Maurizio
>>>
>>> Here under is a suggestion for the implementation of the rule you
>>> stated above (Attr.visitMethodDef(), upon rev. b6960e2da008).
>>>
>>> I kept a check on the callsite for further evaluation (in
>>> Attr.checkMethod() to be more general). I think both are
>>> complementary.
>>>
>>> "<T> T[] List.toArray(T[])" is a good example of a well designed API.
>>> But an invocation of the form "a = l.toArray(null)" is dangerous due
>>> to the obvious API's lack of control over T and might be warned.
>>>
>>> For the Lint category, I suggest to name it "generic" and to use it
>>> for warnings about type variables. Other checks like the "final" one
>>> could fall into the same category.
>>>
>>> Does this look better?
>>
>> Should I create a JBS issue for that?
>
> Yes, please, go ahead. I've seen this popping out frequently enough that I
> think it deserves some closure.

Done: https://bugs.openjdk.java.net/browse/JDK-8189684

Cheers,
Bernard


> Maurizio
>
>>
>> Bernard
>>
>>> Thanks,
>>> Bernard
[prev in list] [next in list] [prev in thread] [next in thread]