I find that confusing in a bunch of other ways. I much prefer the non C style of name : type rather than having the name embedded in the middle of the type.
A bunch of ways? Maybe it's just confusing because you haven't thought about it before.
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;
If you don't have type inferencing, you always need to specify the type, and the let keyword and colon are just more noise. I know it's a matter of taste, but I think the first line is cleaner.
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]
I do actually think about this sort of thing quite a bit, and work with a bunch of people who have thought about these kinds of issues far more than me. I’m firmly of the belief that C style type syntax is never going to not be confusing, and changing the pointer to postfix just changes the places where it’s confusing. Personally I think a core problem is that declaration and use are different, and while I agree that dereferencing is generally much clearer as a postfix operator it doesn’t solve the confusion on the declaration side.
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.
> I do actually think about this sort of thing quite a bit
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@
You could change the declarations to use a "let" keyword, but I don't think it'll make them more readable while maintaining the goal of "declaration follows usage".
> I’m not sure how I would declare the type of a function that returns a pointer to an array
