Improving the UI of generics

Evolution Discussion
19

Thanks @Joe_Groff, I love the direction this is taking, but I’m concerned that in it’s current form it’s introducing too much syntax (without reducing other syntax). Sorry if this is better suited for a different thread, but there didn’t seem to be an appropriate one.

If the generic syntax is already too complicated then I’m concerned adding more syntax will complicate it further as users mix and match. The shorthand is quite distinct from the regular syntax, it’s not a logical extension like .foo instead of MyEnum.foo.

Rust has a lot of awesome features, but is also much harder to learn.

I’m worried this Manifesto currently further conflates generic and protocol syntax, by using more generic syntax for protocols (let’s go all in).

The added syntax and complexity might be a necessary requirement of progress, but I’m wondering if this manifesto could also be an opportunity for simplification.

I don’t like being critical of things without a suggested alternative, so here are some ideas:

Use generic syntax for protocols definitions instead of associatedtype. It’s becoming less clear when protocol is syntactically distinct from generics, let’s see if we can reduce protocol specific syntax.

Make generic arguments on a type shorthand for a typealias. Currently it seems inconsistent when you can use the generic argument name, if you remove associatedtype you’d either want to be able to shadow the generic label with a typealias or have an implicit typealias.

Embrace argument/closure/label syntax for generics. Naming is useful, but you don’t always want to have to do it. Why have a totally distinct way to represent the same concepts for types and values?

Visually:

protocol Foo where
  Bas.Element == Bar,
  Bad.Element == Bar {

  associatedtype Bar
  associatedtype Bas: Collection
  associatedtype Bad: Sequence

}

Becomes:

protocol Foo <
  Bar,
  Bas: Collection< Bar, _ >,
  _: Sequence< Bas >
> {
}

Foo.Bar
Foo.Bas
Foo.$2.Element

Maybe also optional named type arguments, where it’s closer to argument syntax than type constraints:

let x: Collection< Element: String, Index: Int >
3 Likes