[nem-en] overloads & inference

[Michal Moskal]

On 6/16/07, Dmitry Ivankov <divanorama at gmail.com> wrote:
> Hi.
>
> I've found solution to bug 1026, scenario was + -> op_Addition as operator
> -> op_Addition as method (overloaded, only 2 overloads) ->
> fail
> solution is to make + -> op_Addition as operator ->
> op_Addition as overloaded operator (only 2 overloads) ->
> more overloads from better typed args -> ok
> So to make it work I add new
> DelayedTyping.Kind.OverloadedOperator, which do same things
> as Kind.Overloaded, but also do LookupOperator (arg.type, name).

Sounds good to me.

> And here goes the question: how does typing collect all possible overloads?
> Does it fetch new ones when args types become
> more precise?

The operator stays suspended until the type of at least one argument
is known. Actually not even ,,known'' but suspected to be some type T.
If at that point we know also the type S of the second operand, then
we look in both T and S, otherwise we look only in T.

Clearly this is sort of a hack. We just need to use the available
information to somehow proceed with typing. It might be possible to
first try resolving operators only if both types are known, and only
after we're stuck, try to do a single argument lookup. I'm not quite
sure though, if it's worth the effort.

> (maybe extension methods have problem like 1026 too)

I wouldn't think so, because there is just one type involved in name
resolution there, so we either know it, or don't.

> And one more: should we allow using op_Addition-like names as synonims for
> "+" and others?
>  Currently these names are visible only when "using
> class_declaring_op_Addition" and treated as functions only, not as smth like
> synonims of operators.
> While "+" is also visible when it is declared in one of
> it's args class.

What would be the use scenario for this feature?

-- 
   Michał