Why no multiple-dispatch?

[Aerolite via Digitalmars-d-learn]

On Monday, 25 August 2014 at 00:08:25 UTC, Jonathan M Davis wrote:
>
> At this point, if something can be implemented in a library 
> rather than in the language, the odds are low that it will be 
> solved in the language. The language is very powerful and 
> already a bit complicated, so usually the response for 
> questions like this is that we'll take advantage of D's 
> existing features to implement the new feature rather than 
> complicating the language further. If you could come up with a 
> very good reason why it had to be in the language, then maybe 
> it would happen, but my guess is that that's not likely to 
> happen.
>
> - Jonathan M Davis

I definitely get that, and it's the right idea given how powerful
the language is as it stands. :)

With respect to something like Multiple-Dispatch though, this
seems like something that, conceptually at least, should really
be below the library layer. A library solution in this regard is
tantamount to writing virtual method handling as a library
solution, which is obviously crazy talk.

While I understand the strong desire feature-freeze the language
itself (I want the same thing!), I really think this feature is
one we can get at the language level without any real structural
change (i.e. this doesn't seem like something we'd need any extra
syntax for - only a semantic change).

So, to weigh up the pros and cons of each implementation strategy:

Language implementation:
- Pros:
-- No syntax modification (unless you want the feature to be
optional)
-- Extremely low likely-hood of it being a breaking change (no
one really writes functions/methods that could take advantage of
this, currently)
-- Potentially transparent to non-users
-- Potentially faster builds (just resolve the actual type for
each *class parameter*, instead of doing what would likely be a
fair few template expansions)
-- Less code bloat (see above)
-- Overall, shouldn't be very difficult to implement
- Cons:
-- Yet another step away from a language feature freeze
-- We can emulate this with templates
-- Potential for slower builds in large projects that have no
need of it (unless it's optional, but that would likely require
syntactical changes or a new attribute)
-- However small, there's still the possibility that it might
break existing code

Template / library implementation:
- Pros:
-- No changes to the language syntax or spec
-- No chance of any breaking changes
-- No potential build-speed impact for those who don't require it
- Cons:
-- Template bloat (which, as I understand it, is already a
significant issue)
-- Potentially large build-speed impact, depending on
implementation and project size
-- Doesn't scale nicely to run-time dispatch (although I can't
think of a situation where this would actually be a problem)
-- Conceptually the entirely wrong place for this kind of feature
(see virtual method comment above, although this could be
considered subjective)

Just going off that (unless I'm wrong, or have missed something),
a language implementation seems like it would actually be the
best option.

TL;DR:
This isn't a feature that conceptually belongs at the library
level, and a language implementation has the potential to be
transparent to non-users, lessens code-bloat, and would ideally
require only a small semantic change that almost no one would be
negatively affected by.

Also, looking at things from a very vain, marketing perspective,
it'd be a nice little thing to add to the 'Power' section on the
homepage! :P