Why no multiple-dispatch?

Idan Arye via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Aug 25 00:36:21 PDT 2014


On Monday, 25 August 2014 at 02:04:43 UTC, Aerolite wrote:
> On Monday, 25 August 2014 at 01:34:14 UTC, Idan Arye wrote:
>> On Monday, 25 August 2014 at 01:10:32 UTC, Aerolite wrote:
>>> -- No syntax modification (unless you want the feature to be
>>> optional)
>>
>> If this ever gets into the core language, it absolutely must 
>> be optional! Think of the implications of having this as the 
>> default and only behavior:
>>
>> * Every overloaded function will have to do a runtime 
>> typecheck - this not only causes a usually unnecessary 
>> overhead but also has a negative impact on branch prediction.
>
> Well, you'd only have to resolve *class* parameters (since
> obviously literals and structs don't support inheritance). My
> brain is a little foggy at the moment due to this nice flu I
> have, but do we even need to do this at run-time? It's not like
> we can do a Java and use run-time reflection to create new class
> instances. The closest thing we have to that is Object.factory,
> but that's all compile-time built and type-safe as far as I'm
> aware? Or am I being silly?

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.

>> * What if you have multiple overloads that happen to be 
>> templated? Now the compiler will have to instantiate them all!
>
> Hard to say, although surely there could be some examination of
> what is and is not necessary to instantiate. This is again 
> making
> the implementation a tad more complicated, though. That said, if
> something like @multimethod existed, it would assist in this
> matter.

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?

>> Anyways, I don't think you get just how strong this language's 
>> tendency to push features to the library is, so I'd like to 
>> point you to this post by the language's creator:
>>
>> http://forum.dlang.org/thread/lt00a9$2uoe$1@digitalmars.com#post-lt00a9:242uoe:241:40digitalmars.com
>
> Heh. Well, that's Walter for you! :P But I definitely understand
> the push towards the library. I just feel that handling method
> dispatch, even in compile-time template code, is not something
> that we should really be writing ourselves. It's like trying to
> do virtual method calls in C!

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)


More information about the Digitalmars-d-learn mailing list