Naming Some[Trait] and *SomeTypeList[Trait]

Mojo Standard Library
,
1

Based on the following Discord post I start this discussion to decide on the naming of Some and SomeTypeList.

Some can be used to implicitly declare a type parameter while *SomeTypeList can be used to implicitly declare variadic type parameters.

While I think the current naming is viable, *SomeTypeList is quite verbose.

Possible alternatives (updated):

  • Some/*SomeTypeList (the current naming)
  • Some/*SomeTypes (less verbose)
  • SomeType/*SomeTypes (more consistent?)
  • Some/*Each (short and expressive?)
  • Impl/*ImplList
  • Impl/*ImplEach
  • ā€¦

Maybe not feasible:

  • Type/*Types (Type is a reserved keyword)
  • Some/*Some (same name for both not possible?)

Example

# current naming

def foo[T: Copyable, //](arg: T) -> Int: ...

def foo(arg: Some[Copyable]) -> Int: ...

def bar[*Ts: Copyable](*args: *Ts) -> Int: ...

def bar(*args: *SomeTypeList[Copyable]) -> Int: ...

# one alternativ

def bar(*args: *Each[Copyable]) -> Int: ...

The great thing is that Some and SomeTypeList are ā€žjustā€œ comptime type alias and not hardcoded compiler keywords.

BTW: Some is already in the stdlib for quite some :wink: time while SomeTypeList is new. [mojo-lang] Enable autoparam of variadic pack type lists. Ā· modular/modular@b964941 Ā· GitHub
The Some name was already discussed and decided on in this issue: [Feature Request] Rename `InstanceOf` to express trait implementation Ā· Issue #5166 Ā· modular/modular Ā· GitHub

some is used in Swift too.

2

SomeType/*SomeTypes

I can see the value in going in this direction due to consistency and clarity

but Iā€™m not a fan of making Some more verbose given we already have quite descriptive and long-named traits. Iā€™m not opposed to doing it though, since it does provide value in bringing clarity for people unfamiliar with the concept.

Iā€™m 100% pro *SomeTypes above the other cited options, it still follows the lead of our current and alternative Some naming.

However, if somebody does come up with an interesting alternative (for Some or SomeTypes) I think itā€™s worth hearing.

3

In an ideal world I would prefer
Some/*Some
but I think thatā€˜s not possible with the current language constructs and implementation as comptime type alias.

4

I added your proposal to the list.

5

What about something like Type[Movable] and Types[Movable],
i know that ā€œTypeā€ is an keyword we might need later,
just an idea :+1:

6

Why not Impl and ImplList? Reading back through the old Github thread, there was never a strong reason not to use Impl and Some now has two strikes against it: collision with Optional variants (in our heads at least), and it doesnā€™t translate nicely to SomeList.

def foo[T: Copyable, //](arg: T) -> Int: ...

def foo(arg: Impl[Copyable]) -> Int: ...

def bar[*Ts: Copyable](*args: *Ts) -> Int: ...

def bar(*args: *ImplList[Copyable]) -> Int: ...
7

OK, I add it to to list of possible alternatives.

8

IMO The current version feels a little weird

  • Some
  • SomeTypeList

I think ā€œEachā€ fits nice.

  • Some
  • Each

And to throw in another option which combines other suggestions:

  • Impl
  • ImplEach

This feels like a very good combination being short and still clear! :nerd_face:

9

Iā€™m in favor of Some/*Each:

  • Some is well established, short and no abbreviation.
    Semantics: Some type that conforms to the trait.
  • *Each complements Some as it is short and no abbreviation too. It implies plurality.
    Semantics: Each type conforms to the trait.

IMO the names must be short and easy to recognize. This allows for a ā€œconciseā€ implicit alternative to the more complex and verbose explicit syntax.

Example:

def foo[T: Copyable, //](arg: T) -> Int: ...

def foo(arg: Some[Copyable]) -> Int: ...


def bar[*Ts: Copyable](*args: *Ts) -> Int: ...

def bar(*args: *Each[Copyable]) -> Int: ...