Reference implementation

[Paul Benedict]

I can't speak for Neal, so he'll have to respond as he sees fit, but I
think he doesn't believe the "simple" approach is actually expandable
to the "full complex" approach. Am I interpreting correctly?

Paul

On Thu, Oct 29, 2009 at 11:04 AM, Maurizio Cimadamore
<Maurizio.Cimadamore at sun.com> wrote:
> Paul Benedict wrote:
>>
>> I think Neal is asking for proof, but the responses given to him are
>> in the "I believe" category. Is there some way to prove that the "full
>> complex" approach is not cornered out?
>>
>
> What do you exactly mean by cornered out?
>
> Maurizio
>>
>> Paul
>>
>> On Thu, Oct 29, 2009 at 10:37 AM, Maurizio Cimadamore
>> <Maurizio.Cimadamore at sun.com> wrote:
>>
>>>
>>> Neal Gafter wrote:
>>>
>>>>
>>>> On Thu, Oct 29, 2009 at 2:48 AM, Maurizio Cimadamore
>>>> <Maurizio.Cimadamore at sun.com <mailto:Maurizio.Cimadamore at sun.com>>
>>>> wrote:
>>>>
>>>>   Neal, the complex-full approach is essentially your approach plus
>>>>   some magic to make the following work:
>>>>
>>>>   Foo<Object> = new Foo<>(1);
>>>>
>>>>   That is, a complex approach that takes into account the expected
>>>>   return type in order not to infer a type which is too specific.
>>>>   Such an approach would be compatible with the currently
>>>>   implemented simple approach (in fact, ANY other approach that
>>>>   takes into consideration the expected return type would be
>>>>   compatible with the simple approach).
>>>>
>>>>
>>>> Are you telling me that you're confident that such "magic" can be
>>>> specified, and implemented, and retrofitted onto the implementation of
>>>> generic method invocations and argument contexts, without any deep
>>>> issues?
>>>>  If so, I'm satisfied.
>>>>
>>>
>>> I think such an approach does exist - on the other hand if it didn't, it
>>> would mean that there is no way (other than the simple approach) to
>>> support
>>> the use case I mentioned several times in this thread.
>>>
>>> Maurizio
>>>
>>>
>>>
>>
>>
>
>