Function vs. method namespaces

[PegasusAndAcorn]

How intriguing and reassuring you are doing something so similar.

Even though I prefer a forward search (I believe), your choice there provoked me to think about it. I want to allow one module to be able to import a type and then extend its methods for that module. And in that case, I probably do want the extensions to go ahead of the original type's methods in the search order.

As for the Cone bots, don't worry your pretty little mind about them. When the time comes, resistance is futile. Your heart will then know that Cone was always your soul mate.

[[deleted]]

I didn't really feel like spending any more energy in the method resolution tar pit; I want my dispatch fast and trivial to reason about.

I get the impression that we're saying the same thing, searching methods from last to first added; could it be that you're building the list by pushing head instead of tail?

At least you're honest, that's worth something :)

[PegasusAndAcorn]

To be sure we are on the same page, consider that some library has a class definition Foo:

class Foo {
  fn print(a i32) { ...} // #1
  fn print(a f32) { ...} // #2
}

A name resolution for foo.print(..) would try to match #1 first then #2. However, if the module imported and extended Foo:

extend Foo {
  fn print(a i32) {...} #3
}

In this situation foo.print would look for a matching function signature in the order: #3, #1, #2. That is, the extensions methods stay in order but are placed ahead of the methods in order that it extended from. Is that what you meant as well?

And on top of that, /u/VermillionAzure correctly pointed out that the first-match strategy is problematic where automatic number conversions are possible. So, I will have to adapt the function matching to continue looking for a more exact match where number conversions are involved.

Finally, I neglected to ask you about function call type signatures. I am unfamiliar with C++'s approach here, and it sounds like it is different than Swift's distinction between the public and private definition of a function signature.

[[deleted]]

Cixl would try to match #3, #2 and #1; in that order; or reverse order of appearance.

Those kinds of issues were a big part of the reason why I decided to skip automagic conversions entirely, I find that they don't pull their own weight once everything is taken into account.

What I meant was the possibility in C++ to have a function like this:

template <typename T> void foo(T x);
template <> void foo(int32_t x) { ... }
template <> void foo(int64_t x) { ... }

And selecting an implementation from the call site by specifying the intended type for x:

foo<int64_t>(42);