Why no multiple-dispatch?

Aerolite via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Aug 25 03:02:41 PDT 2014


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.

> 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?

> 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.


More information about the Digitalmars-d-learn mailing list