Use the dot operator to remove nesting of generic brackets in type expressions

[LPTK]

Apologies if that was already considered/discussed somewhere (the only thing I found was this old discussion).

Why not use the dot operator in types in a way that mirrors its usage in expressions? By that, I mean that B.A could be equivalent to A<B> and B.A<C,D,...> to A<B,C,D,...>.

This could get rid of a lot of pesky angle brackets, and it also reads very naturally IMHO. This is similar to OCaml’s generics, where int option list means List<Option<Int>>, or with the new syntax Int.Option.List or List<Int.Option>, read “a list of int options”. Also compare:

HashMap<Vec<String>, Vec<Rc<Cell<i32>>>>
// and
HashMap<String.Vec, i32.Cell.Rc.Vec>

I did not see an incompatibility with the way operators are currently used (in that way it’s nice that :: is used for namespacing instead of .). Any comments?

[atagunov]

… wouldn’t the reverse read even better?

HashMap<Vec.String, Vec.Rc.Cell.i32>

[jmst]

The main issue is that generics can have multiple parameters, and due to default parameters the number is not constant, so this syntax cannot be exclusively used because it would be ambiguous.

Lots of the common generic types don’t have any defaults and also have only one parameter, so maybe this could have some use, but not sure if it’s worth requiring newcomers to learn another generic syntax just for some minor sugar and having code half in one style and half in another style.

[LPTK]

not sure if it’s worth requiring newcomers to learn another generic syntax

Note that to some extent, the syntax already has to be learned for methods – which can be called either with x.foo(y) or foo(x,y). It’s really just the UFCS (Universal Function Call Syntax) in action but on the type level.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.