On Monday, 25 August 2014 at 17:28:45 UTC, Ola Fosheim Grøstad wrote:
> Then extend the typeinfo of classes in the first param with a minimal typeid and 2D table that lists all combinations that the "custom linker" can find based on the mangling?

Maybe it would be better to put in the restriction that all double-dispatch functions with the same name are located in the same file.

On Monday, 25 August 2014 at 17:16:10 UTC, Idan Arye wrote:
> 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.

Yes, you're 100% correct. I misinterpreted what you meant. My
bad! :P

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

I guess not, although I'm still concerned with build time
increases. Perhaps I shouldn't be, though.

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

Well if this was to become a language feature, I think the best
way to do it would be a new annotation (@multimethod) on each
overload of a certain function, and then during the semantic
analysis phase look at invocations of these functions, inserting
appropriate casts to the actual object types of any class-type
input parameters. Would this work? If so, that should require no
changes to the backend. Now obviously it's not going to fit
nicely with the standard overloading mechanism in the case of
calling a more abstract overload, but that is why it'd be an
annotation rather than by-default (although you might be able to
get around this by inserting an up-cast manually).

By the way, sorry if I'm sounding a little silly at times. I'm an
undergrad in Computer Science who's just started a course in
Compiler Design, so please forgive me for any obvious holes in my
knowledge of the compilation process (or other areas) as I'm
still learning it! :P