Overload resolution simplification
Ali Ebrahimi
ali.ebrahimi1781 at gmail.com
Thu Aug 15 15:54:37 PDT 2013
Hi,
On Fri, Aug 16, 2013 at 2:57 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:
> On 15/08/13 23:21, Ali Ebrahimi wrote:
>
> Hi Maurizio,
>
> On Thu, Aug 15, 2013 at 5:00 PM, Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> wrote:
>
>> Here's an example in C# that features similar problems as the
>> Comparator.comparing
>> Don't get me Wrong. If you have in mind I said we can learn from C# not
>> copy it as C# learned (even copy) from java in past.
>> So my intend is combination of current java solution (assignment
>> context inference which C# does not support) and C#'s one (lambda return
>> type inference).
>>
> I guess then I'm missing what is that you think makes C# lambda return
> inference different from what we have in Java
>
My concerns is for overloaded methods with lambda arguments, which
currently compiler give up them.
>
> We type check lambda body only if all its input type arguments already
> inferred from inference context:
> static class Test<T>{
> Comparator<String> m(){
> return Comparator.comparing(t -> t.length()); [1]
> }
>
> static <P> void m(Comparator<P> c, P t){
> return;
> }
>
> void m(Comparator<T> c){
> return;
> }
>
> void test() {
> new Test<String>().m(Comparator.comparing(t -> t.length()));
> [2]
> ((Comparator<String>)Comparator.comparing(t ->
> t.length())).toString(); [3]
> Comparator<String> c = Comparator.comparing((String x) -> 0);
> [4]
> m(Comparator.comparing((t) -> t.length()),""); [5]
> }
> }
>
> For overloaded methods we act in multiple phases.
> phase1: we do type check lambda without boxing, unboxing and widening in
> return type.
> if we get only one overload that successfully type checks lambda So
> inference has been succeed, otherwise go phase 2.
>
> phase2: we do type check lambda without boxing and unboxing but with
> widening in return type. if we get only one overload that successfully type
> checks lambda So inference has been succeed, otherwise go phase 3.
>
> phase3: we do type check lambda with boxing, unboxing and widening in
> return type. if we get only one overload that successfully type checks
> lambda So inference has been succeed, otherwise ERROR.
>
> Do you plan to use information about i.e. assignment context when doing
> steps 1/2 ?
>
yes, of course for inferring method's type args and finaly for lambda's
input type args.
Regards,
Ali Ebrahimi
More information about the lambda-spec-observers
mailing list