generics specialization doesn't work if used indirectly

There is no simple way to resolve as you wish at compile-time. Either also add a A overload for a specific type (`int' here) either add logic in B[of T](T) to redirect to B(int) if T isa int.

Feel free to reopen if there is something I overlooked.

It's not a matter of not being able to resolve it this way: this is by-design. Overloads are selected at compile time, not at runtime.

The int version of B is not a candidate for the invocation B(t) inside A because the parameter type T is not known to be assignable to int. What happens when you call it afterward, indirectly, is irrelevant for this decision.

Stressful day Avish?

Keywords were "simple", "as you wish" and "compile-time". I closed the bug because it is indeed obviously by-design.

The "not-simple-yet-not-very-difficult" way I implied, when/if such a kind of generic multiple dispatch is desirable, is to write and apply an AST attribute on method A[of T] that would create specialized non-generic overloads of A depending the signatures of the methods directly invoked by A (here the fact B(T) has a B(int) overload would make `A' a candidate for an automatic specialization overload A(int)).

In fact here is a preliminary version* of such a [autoSpecialize] (autoGenericDispatch?) AST attribute applicable on generic methods: http://pastie.org/536185

*: very basic/hackish but works for simple cases such as the above testcase, for as many available specializations B has, wherever the parameter is located. Dmitry you're welcome to improve on it and post your updates here

What I tried to say is that this behavior is problematic to say the least, not in terms of implementation but because it breaks the way overloads are handled and can yield to confusing bugs; that's all. Even if it is possible to auto-specialize as you described, I think a feature like this will do more harm than good. But that's my own (stressful) opinion, of course