For functions, I think the -> syntax is the only thing that makes sense. It's just natural, first you need the arguments then you get the return value.
> That would mean you have 2 styles of pointers, one as a prefix and one as a suffix to the declarator identifier. So you now have to read both right-to-left and left-to-right, which seems to cancel out the benefits of only reading declarations in left-to-right order!
I'm not following. There are not two styles of pointers, a pointer is declared like "&type". Functions are declared like "(args) -> ret" which is read left-to-right (function taking such arguments and returning such value). A function pointer is simply a pointer to a function like "&(args) -> ret".
> Q: How do these proposed changes affect the parsing of the new C syntax?
I guess I should have added </sarcasm>? C would never adopt such a radical change. In any case, I don't see how it would be fundamentally more difficult to parse than the current declaration syntax. There would be problems disambiguating the two (what is "foo bar;" if foo and bar are both typedefs?). Maybe changing to require a colon after the name would make that simpler "fun: (arg: int) -> int".
By 2 styles of pointers used in functions, see below taken from your examples.
By reading both left-to-right and right-to-left I mean:
"star" pointer in front of the identifier read right-to-left with return function type on the left
and ampersand pointer read left-to-right with return function type on the right of "->"
Here are 2 of your function examples you gave:
This example has both an outermost "void" function return type on the left and another to the right of "->"
"void (* f)(g &(int) -> void)"
Instead use the following to always read left-to-right and get rid of the "star" pointer:
"f &(g &(int) -> void) -> void"
Your next example has 2 "void" function return types on the left, and one "void" to the right of "->"
"void (* f)(g &(void (* h)(x &int)) -> void)"
Instead use the following to always read left-to-right:
"f &(g &(h &(x &int) -> void) -> void) -> void"
I did say "original C declaration syntax forms needs to be deprecated and only the newly invented syntax forms should be used". So the new invented syntax alone is complete (you can express anything with &, (args)->ret and [count]type).
For functions, I think the -> syntax is the only thing that makes sense. It's just natural, first you need the arguments then you get the return value.
> That would mean you have 2 styles of pointers, one as a prefix and one as a suffix to the declarator identifier. So you now have to read both right-to-left and left-to-right, which seems to cancel out the benefits of only reading declarations in left-to-right order!
I'm not following. There are not two styles of pointers, a pointer is declared like "&type". Functions are declared like "(args) -> ret" which is read left-to-right (function taking such arguments and returning such value). A function pointer is simply a pointer to a function like "&(args) -> ret".
> Q: How do these proposed changes affect the parsing of the new C syntax?
I guess I should have added </sarcasm>? C would never adopt such a radical change. In any case, I don't see how it would be fundamentally more difficult to parse than the current declaration syntax. There would be problems disambiguating the two (what is "foo bar;" if foo and bar are both typedefs?). Maybe changing to require a colon after the name would make that simpler "fun: (arg: int) -> int".