The biggest problem with C's pointer syntax is that it's prefix to the value.
int p*
int *p
C's array and function syntax have exactly the same issue, the entire thing is back-asswards.
Let me demonstrate by converting your examples to a more regular (and logical) language[0]:
let i: i32 // integer
let i: Box<i32> // pointer to integer
let i: fn() -> i32 // function returning an integer
let i: Box<fn() -> i32> // pointer to a function returning an integer
let i: fn() -> Box<i32> // function which returns a pointer to an
let a: [i32;10] // array of 10 integers
let a: [Box<i32>;10] // array of ten pointers
let a: Box<[i32;10]> // pointer to an array
let a: [fn() -> Box<i32>;10] // array of ten functions that return a pointer
[0] which doesn't mean perfect e.g. one could argue against the special syntax for arrays
Boxes are containers, not pointers or references. Let's look at all of those those using the star syntax and operator inside of an unsafe block? You'll end up with stuff like:
fn main() {
let mut a = [0i32; 10];
let p: *mut [i32] = &mut a;
// Rust did NOT solve this problem
let x: i32 = unsafe { (*p)[1] };
print!("{x}\n");
}
There is no actual difference between the two. Pointers and references could have been `Pointer<T>` and `Ref<T>` with the exact same ABI. They're not for UX reasons, one of similarity with C, and one of syntactic overhead.
> // Rust did NOT solve this problem
> let x: i32 = unsafe { (*p)[1] };
That is a debate of precedence, which is a very different concern than what I was replying about, and what TFA is about: the absurd mess that are C type declarations.
Rust has raw pointers, references, slices, and arrays, each with special syntax in type/variable declarations. You're conflating those with Boxes, and it isn't adding clarity to the discussion. It's not like C++ removed this problem now that people use `std::unique_ptr<T>`.
Rust's raw pointer syntax is exactly as bad as C's, because it's the same syntax. Yes, it could use some other syntax like `Ptr<T>` for declaration, but it doesn't. And that still says nothing about what operator syntax to use when dererencing the pointer.
Perhaps it could be:
let p: Ptr<T> = whatever;
let x = p.deref(); // suffix syntax!
It's not a different concern, and it's a problem no matter what the precedence. If prefix pointer syntax binds tightly, you'll need parens in one case. If it binds loosely, you'll need parens in another case:
*(binds_tightly.foo[10]); // subscript the array first because star binds tightly
(*binds_loosely).bar[10]; // dereference the pointer first because star binds loosely
> (the absurd mess that are C type declarations)
Hating on C is trendy, that's fine. But a lot of people are confused about what the problem really is. It could be fixed with one change, but since people can't see it clearly, they change everything. And in cases like Go or Rust, they change almost everything and still don't solve the problem.
A language could achieve C's goal of "declaration follows usage" if pointers had suffix syntax. The prefix pointer syntax is where crazy "winding rules" and "Gibberish to English" translators come in.
However function calls, array subscripts, and field accesses are the same "kind" of operation as dereferencing a pointer. Put the type last if it makes you happy, but you'll have "horrible" syntax if you don't treat pointers the same as the others:
something.bar[10]() // access the field, subscript the array, call the function
something.foo@ // access the field, dereference the pointerNot really? Assuming type and variable names are lexically distinguishable via the lexer hack or, say, capitalization. Here’s an LR(1) grammar (in Grammophone[1] syntax) with postfix types and dereferencing:
stmt -> init ; | expr ; .
init -> decl | decl = expr .
decl -> dtor type .
dtor -> ambi | dfun .
dfun -> ambi ( decl ) | ambi ( darg ) | dfun ^ | dfun ( ) .
darg -> decl , | darg decl , .
expr -> summ | summ = expr .
summ -> prod | summ + prod .
prod -> post | prod * post .
post -> ambi | efun .
efun -> ambi ( expr ) | ambi ( earg ) | efun ^ | efun ( ) .
earg -> expr , | earg expr , .
ambi -> name | ambi ^ | ambi ( ) .
# Stub
type -> int .
name -> x .
Whether this is a smart idea as far as ergonomics of syntax errors go, I don’t know.
Hah, I appreciate your point and careful reply, but that's quite an assumption :-)
I think using capitalization does qualify as "another syntax", which I was cautious to qualify. And (as you know) the "lexer hack" means you need to declare your types before you use them, which is a bummer for mutually recursive types.
Anyways, I'll concede that you're right in that you can do it, but I don't think I was very wrong :-)
Which actually led me to make an error here. The starting point was C syntax so I thought assuming a lexer hack was fair game, but the grammar above doesn’t actually need it! It doesn’t need one even if you add parameterized types with the same syntax as function calls. It only needs it if you want to write function calls as juxtaposition without parens ML style, use infix syntax for type application, or (and that is what I have been fiddling with) drop the semicolons.
(D'oh, I knew I was forgetting something! It was parenthesized expressions. And apparently I also screwed up optional comma termination. And curried calls.)
So, for example, you can add these productions to the grammar above and it still stays LR(1):
# Remove lexer hack, add parameterized types
type -> name | type ( ) | type ( type ) | type ( targ ) | type ( targ type ) .
targ -> type , | targ type , .
# Fix the stupid
dfun -> ambi ( darg decl ) | dfun ( decl ) | dfun ( darg ) | dfun ( darg decl ) .
efun -> ambi ( earg expr ) | efun ( expr ) | efun ( earg ) | efun ( earg expr ) | ( expr ) .
Don't think I've ever constructed a more complicated type ('directly' so to speak, i.e without typedefs) than an array of function pointers (array of interrupt handlers, taking no arguments, returning void).
99.999(repeating)% of the time I use a typedef for function pointers and nothing looks particular complicated.
And there are a lot of people who want to throw the baby out with the bathwater. Go is the one that really amuses me here: They broke the "declaration follows usage", which I think is a nice idea, and they still have backwards pointer syntax that needs parentheses to get it right.
> Don't think I've ever constructed a more complicated [...]
Heh, I'm not sure this is a great argument. It's kind of like saying you don't care about the complexity/details in floating point because you've never needed more than integers. :-)
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] ...[0]: https://nathancraddock.com/blog/consistency-in-zigs-type-sys...
var value: i32 = 0;
The array syntax makes even less sense!
I think what you’re missing in your examples is how the values are used after declaration. C syntax was designed so that declaration resembles use. The reason array subscript brackets come after the variable name is because that’s how you access elements of the array:
int arr[3] = { 12, 76, -42};
arr[1] += 4;
if (arr[2] < 0) { printf(“it’s negative!\n”); } int *foo = &bar;
*foo = 1;
int* foo = &bar;
I would say `v := (p.)` could've been the deref operator, but what do I know.
What fixes this issue is that, like most other languages which are not C, Go understands that "is a pointer" is a property of the type, not the name / value.
So even if it used C-style declaration, Go would say
*int p
Pointer[int] p int * a, b; // "Property" of the variable
typedef int * pint;
pint x, y; // Property of the type
https://go.dev/blog/declaration-syntax
He suggests Pascal's caret syntax (^), which wouldn't work if it was also used as the binary xor operator.