Boo
  1. Boo
  2. BOO-1213

generics specialization doesn't work if used indirectly

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: 0.9.1
    • Fix Version/s: 0.9.2
    • Component/s: Compiler
    • Labels:
      None
    • Environment:
      WinXP SP3, .Net 3.5b, #D 3.1b
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      def A[of T](t as T):
      	B(t)
      def B[of T](t as T):
      	assert not "supported"
      def B(t as int):
      	print t
      B(12)   //prints 12
      A(12)   //assertion
      

        Activity

        Hide
        Cedric Vivier added a comment -

        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.

        Show
        Cedric Vivier added a comment - 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.
        Hide
        Avishay Lavie added a comment -

        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.

        Show
        Avishay Lavie added a comment - 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.
        Hide
        Cedric Vivier added a comment -

        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

        Show
        Cedric Vivier added a comment - 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
        Hide
        Avishay Lavie added a comment -

        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

        Show
        Avishay Lavie added a comment - 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

          People

          • Assignee:
            Unassigned
            Reporter:
            Dmitry Malyshev
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: