In my opinion, `Vector int` is the more logical syntax. `Vector[int]` to me seems like a vector indexed by int (rather than containing int), much like `map[int]T` is a map indexed by int, and `[5]T` is an array indexed by an integer less than 5.

For the same reason, I dislike `std::array<T, 5>` which puts the range type before the domain constraint. This is inconsistent with `std::map<int, T>` which puts the domain type before the range type, and `[](int x) -> T` which puts the domain type before the range type.

> `Vector int` is the more logical syntax.

This introduces several parser ambiguities, esp. related to nested template types or types with multiple parameters. For instance, does `Foo Bar Baz` read as `Foo(Bar, Baz)` or `Foo(Bar(Baz))`?

Right. For consistency, the old built-in generics should be written

    var v chan(int)
    var m map(keytype,datatype)
    

instead of

    var v chan int
    var m map[keytype]datatype

but, for backwards compatibility, that probably won't happen. Thus, cruft.

Map was always a bit too special in Go. Channels really are special; the compiler knows quite a bit about channels, what with "select", "case", and "go" keywords and their machinery. But maps are just a built in library object.

If you want a dynamically sized vector pointing to a datatype, I think `Vector [] Value` is most "semantically meaningful". And if you want to define your own map, `Map [Key] Value` is most self-explanatory... now that I look at it, I'm starting to feel that this introduces too many special cases and complexity into generic syntax to be useful for the actual language parser. I might stick with that in documentation/comments instead.

I wonder if at least they will add this as an additional way to define them and deprecate the old ones without disabling them.

They won't. Go leans very hard towards "there is exactly one way to do it".

I know they won't but now there are 3 ways to express the same idea!