I think a proper type system that doesn't special-cases arrays are better, e.g. Array<String>. Pointers may also be part of this uniform structure, e.g. Array<Ref<String>>, and there is zero question on how to parse it even if you are not familiar.

that's the beauty of type after name, it's all left to right, even in special-cases of array, references, and the most confusing-contributor to cdecl: functions `func(int)[5]*string`: perfectly clear, just read left to right.

What about a Map<int, String>?

You can't really encode a tree structure with only linear semantics (without at least something like s-expressions).

And type declarations are s-exprs.

The advantage of type after name is that it keeps the traversing order consistently pre-order (node, left, right), instead of either:

- the notoriously ridiculous spiral cdecl: reading stuff right (output), node (func name) and left (input)

- create a new name to describe the function in pre-order: Func<Input, Output>

But you can't know how many parameters do a user-defined "node" have. I don't see how it can work for generic data structures without a specific syntax for "the children of this node". Go also uses [] for generics, doesn't it?

At that point I find a uniform system (without special-casing arrays and pointers - they are also just types) would be simpler.

I like the way Dlang does it. It keeps the types on the left like C, but are actually readable.

even better, they should have it above or below!

or, declare the type separately, like in fortran or haskell (or in fact, pre-C99 c)

declare the type separately didn't solve the of hard-to-read cdecl problem.

true; but at the same time, any sufficiently complex type is begging to be type-aliased into something more legible/sensible in the first place ... and this is also true for "right-typed" systems.

I've seen julia types unnecessarily fill a whole terminal for otherwise simple operations before, and I have to say I wasn't too impressed...