Why no multiple-dispatch?

[Idan Arye via Digitalmars-d-learn]

On Monday, 25 August 2014 at 10:02:41 UTC, Aerolite wrote:
> On Monday, 25 August 2014 at 07:36:22 UTC, Idan Arye wrote:
>> If multi-dispatching is done at compile-time, it can't rely on 
>> the object's runtime type - only on the static type of the 
>> reference that holds it. This is no different than regular 
>> function overloading that we already have.
>
> Well any library solution has to do this at compile-time... I
> assume the implementation would be similar, albeit easier 
> because
> the compiler would have all the necessary information directly
> accessible.

This CAN NOT BE DONE at compile-time, since the compiler doesn't 
know at compile time the exact subclass of the instance it'll get 
at runtime. To clarify: I'm not talking about the creation of the 
multi-method mechanism - which *can* be done at compile-time - 
I'm talking about invoking that mechanism to determine which 
overload to call, and this can only be done at runtime.

>> Are you suggesting the compiler will try to resolve the 
>> polymorphism at compile-time, looking at all possible paths 
>> that lead to a function call to check all possible runtime 
>> values it's object arguments can get?
>
> Is that not what would have to be done for a library solution in
> this case, anyway?

If you look back, you'll notice this argument(and the two before 
it) was not against multi-methods at the language level - it was 
about multi-methods by default. If they are optional, 
instantiating all the overloads will only happen when it's used, 
so it won't be that bad.

>> Virtual methods in C can be done with GObject - though the 
>> syntax is awkward. D is so much better than C when it comes to 
>> metaprogramming, that the syntax for multimethods wouldn't be 
>> awkward(unless you consider anything that's not burned to the 
>> core syntax awkward)
>
> Of course, I understand this. What I'm saying is that while it's
> possible to do virtual method calls in C, the very fact that it
> had to be implemented so awkwardly meant that a library solution
> was not ideal. Now in D, the syntax is infinitely better, given.
> Templates and compile-time code-generation are all really good.
> But as I said, we have a lot of template bloat issues already.
> Running 3 foreach-loops at compile-time every time that
> template-function gets instantiated doesn't seem scalable to
> me... Having something like this in the compiler, which has all
> the required information available directly, seems like it'd be
> the most scalable solution.

No one is trying to claim that a library implementation will be 
superior to a language-level solution in terms of speed, memory 
usage, binary size, compilation speed or syntax elegance. 
Language-level solutions can usually achieve better results in 
these regards. The problem is that they come with a price:

  * External tools needs to be modified to work with them.

  * Alternative implementations need to implement them(even though 
the frontend is shared, there can always be some 
complications(plus I think mutli-methods might need some backend 
modifications as well, thhoguh I'm no expert on that matter))

  * Risking regressions - changing the code will never be as 
orthogonal as changing the data it works on...

The point is that the usefulness of multi-methods, and the 
inconvenience of having as a library solution are not nearly big 
enough to pay that price.