Struct's extendability

Mojo
, , , ,
1

Given Mojo’s syntax of ‘implementing’ a trait for a struct, e.g.:


trait Permissable:
    ...

struct Permission(Permissable):
    ...

This would mean that there is no way to ‘implement’ a local trait on a foreign type syntactically because I am unable to write something like:

from foreign_package import ForeignType

struct ForeignType(*ForeignType.__traits__, Permissable):
    ...

In Rust, the impl LocalTrait for ForeignType {..}; works well for extendability. Similar for Scala with its extension keyword.

What is Mojo’s plan for this?

2

I don’t think Mojo supports this yet. Their roadmap says that they’re currently not focusing on syntatic sugar right now.

3

Swift-like extension which should enable something like this is on the roadmap [1]. Mojo’s current trait is limited in many ways and is currently blocking a lot of work in the stdlib. It seems some more work needs to be done in the compiler to enable the team to work on improving traits.

  1. Mojo🔥 roadmap & sharp edges | Modular
4

It is not merely a syntatic sugar because there is not even a syntatically possible way currently to implement a local trait for a foreign type.

But I guess something has to give, and I reckon it will be the syntax, and likely to be a new keyword.

5

The current ask from external stdlib contibutors is for other type system features, since right now we’re trying to build out the stdlib to have basic common abstractions. The feature you are describing is on the list we gave to Modular, but it’s a few items down due to implementing a trait for a type you don’t own being a rarer usecase since a lot of what is in Mojo right now is fundamental work and the stdlib team at modular + external contributors are able to help with upstreaming sensible abstractions. This will change as Mojo scales up, but for now we want to prioritize things that empower code inside of a single library so that we can build up those core abstractions. This include things like parametric traits, potentially effect generics, and some features needed for C interop like raw unions, layout controls, and a few other things.

6

Hi @owenhilyard

Thank you for your reply.

Actually, I thought about it, the inheritance syntax can still be used for local trait implementation for foreign types and for foreign trait implementation for local types.

Because one can imagine…

for foreign type, local trait:


from foreign_lib import ForeignType

struct ForeignType(LocalTrait):

     fn local_trait_method(...):
        <impl details>

Similarly for foreign traits, local type, which is already what is present in current Mojo.

If we are willing to treat each struct definition block as an implementation block, then will make the syntax coherent I guess?

7

The main issue isn’t adding the syntax. That will take someone who knows the parser well a day or two. The issue is all of the modifications required to the trait resolution logic and the type system, which is much more involved.

It’s like someone asking for an “AGI question and answer endpoint” in a REST API. It doesn’t take that long to stub out the public interface, but the backend is a lot of work.