Overloading struct methods from free functions, or the purpose of methods vs functions

[AriMKatz]

regarding this example:

struct Array[T: AnyType]:
    fn __getitem__(self, idx: Int) -> T: ...
    fn __getitem__(self, idx: Range) -> ArraySlice: ...

I was told it's not possible to overload struct or class methods from free floating functions? In julia (sorry for bringing Julia up again, but it's my reference for understanding these sorts of features) it's really nice to be able to register new functions for a type without subclassing or monkeypatching. For example, in this case I might like to define a getitem but perhaps for a custom range type in a third party package without a trait subtype

This type of things is key to Julia's modularity and code reuse. Can it be considered for mojo?

[lattner]

There are alternative ways to address the same thing, e.g. check out how extensions work in Swift. We'll need to look at this whole area as traits come in.

[AriMKatz]

Yes but my impression was that extensions are single dispatch? I guess if extensions were able to dispatch on multiple types then it's not really meaningful difference. But at that point what's the purpose of privileging the first type syntactically? I guess it's pythonic convention.

Perhaps I'm asking too much out of a language based on python and with mojo's goals. Julia's extreme zero cost composability involves concessions (for now ) and maybe mojo wants to stay away from that part of the design space.

[AriMKatz]

Now that I'm thinking about it, I guess if you want to have a function with n different parameters affecting dispatch it wouldn't be a method anyway?

The only issue with that is that magic methods are privileged -as operators and interfaces. Free floating functions would lose out on that, no?

[lattner]

We don't have a goal of providing the Julia multimethod dispatch thing. There isn't an efficient way to implement that other than full monomorphization, it is better to express the same thing with generics, which we haven't designed yet. Let's build out the traits system and see what the limitations are.

Just to be clear, I'm closing this right now just because it is too early to track this, not because it is necessarily a bad idea, thanks!

[AriMKatz]

Understood, thanks. Looking forward to learning more about the trait design