There's certainly a tiny trade-off about where to put the core type name. If you have a "let" keyword, your declaration is just a little more verbose:
int foo[10];
let foo: [10] int;
But my point isn't about where to put the core type (int). It's that pointer dereferencing is the same kind of operation as array subscripting, accessing fields, and calling functions. So unless you put it in order with the rest, you need ugly parens in any general case:
// prefix pointer syntax is convoluted and needs parens:
(*(x.foo.bar))("arguments")[10];
// grab field foo, then field bar, then derefence pointer,
// then call function, then subscript array
x.foo.bar@("arguments")[10]When reading your examples I found myself having to constantly second guess the precedence of arrays and pointers, and I’m not sure how I would declare the type of a function that returns a pointer to an array, or an array of pointers. I’m happy to accept the extra noise of let because it reduces the overall time needed to understand what code means, and we end up reading code so much more than we write it.
Forgive me for being abrasive above.
> I’m firmly of the belief that C style type syntax is never going to not be confusing
Yeah, C is going to stay C. No fixing that. The bummer is when new languages repeat the problem because they don't understand what causes it.
> Personally I think a core problem is that declaration and use are different
I claim that declaration and use can be the same. In all cases, you read the affixes for arrays, pointers, function calls, and struct/union fields from left to right.
// declarations
int i
int a[10]
int f(int arg)[10] { ... }
int p@
// usage
print i
print a[1]
print f(1)[1]
print p@
> I’m not sure how I would declare the type of a function that returns a pointer to an array
// function, pointer, array
int f()@[10] ...