And why change something like that? The world would be a better place, IMHO, if there were less different ways to write something from language to language.
Sometimes it seems like the change is just to make it different, not better.
Sometimes it seems like the change is just to make it different, not better.
The whole point of Zig is to fix C's mistakes. I don't know why they'd repeat this one.
I wish they'd got it right for (de)referencing too though.
is it a method call? is it a property/field value? how am i to be indicated that there is an implicit suspend point when you .await?
In the ideal world, we wouldn't have unary prefix operators at all, but unfortunately unary +, -, and NOT are prefix mostly because they were that in math notation and got grandfathered in (bonus points to Smalltalk here for going with consistency here - "not" and "negated" are regular nullary methods there so it's postfix throughout!). However, these are rarely themselves an operand of another unary operator, so you can mostly deal with this by giving postfix higher precedence than prefix in all cases, so at least it's a simple rule. But then for pointer dereference, it is in fact common to have the result of a dereference itself be an operand in the middle of another expression.
So now you have some choices to make. If you make the pointer dereference prefix, then you don't need extra parentheses when applying other prefix operators to it, e.g. -*p or !*p. If you make it postfix, then you don't need extra parentheses when applying other postfix operators to it, e.g. (using Pascal-style ^ for dereferencing) p^[0] or p^.x. Alternatively, you could add special postfix operators that desugar into the combination but avoid those extra parens, which is what C did with -> for field access.
(Technically, you could also make everything prefix instead, e.g. field access ALGOL 68 style: `month OF birthDate OF person`. But this is very counter-intuitive with indexing, and also makes code completion unusable, so it's not a serious option.)
Although I agree that await could use some precedence like new in javascript:
new types.Date().toJSON()
// fine
await readdir(…).filter(…)
// oops
Neither, honestly. They both look terrible.
bar = await foo()
await bar.coro(*args)
—Andreas Rumpf
Ada does the same exact thing, except there you write `p.all` instead.
In any case, while the exact syntax may not be ideal, using a postfix operator for dereferencing is vastly better than prefix in practice due to typical patterns of use. There's a reason why you end up writing () a lot in C code with heavy pointer operations - the things they end up mixed with most often turn out to have the wrong kind of priority and/or precedence more often than not. Things are much simpler when everything is postfix and code reads naturally left-to-right.
It’s not that important though. Many people write two or more languages without mixing the syntax.
p.* and lv.& would be good post-operators, imo. Less going left and parenthesizing.
The alternative to if-else would be something like `assuming-otherwise`.
The point was that there wasn’t really a pressing need to reinvent the *p/&p syntax.
f(*g(*x)) is just as good as f(g(x*)*)
Hmm, function names go before parentheses, that looks like a good reason for dereferencing to be prefix too, otherwise they end up a long way apart.
But in the back of mind I'm thinking "semantics cause pointless fussy arguments, all code is ugly, let's stop programming in text somehow".
But this is literally not semantics. Semantics is everything of value, this is just syntax.
x()->g()->f();
All it requires is that the function returns a pointer to a struct which itself contains function pointers.
C also allows the dot form if you really want it:
x().g().f()
Now to make it a bit more usable, one needs a bit of planning so that either of these can be done:
x(&x_out).g(&g_out, x_out).f(&f_out, g_out);
x(&x_out)->g(&g_out, x_out)->f(&f_out, g_out);
Where there is a VFT in each of the xxx_out structures, and the calls simply returns the VFT, while the whole abstraction is stored/returned via the out arguments.
when a value is dereferenced, having a consistent left to right dereferencing makes sense.
for example, in c, without looking up the order of operations how confident are you that you know what is going on in the following:
foo = **bar[10]
(Yes, C programmers will probably hunt you down if you do this, but it does work.)
This syntax is less arbitrary than C's. It draws a syntactic parallel between accessing a single member and accessing "all members". (by using pattern-matching-like syntax)
It makes the language more consistent and one's mental model of it smaller. (Even though I doubt that patterns other than the Kleene star would work)
A parallel with files:
cp dir/a dir/b dir/c /other/dir
cp dir/* /other/dir
cp *dir /other/dirBut it seems like I'm in the minority, so maybe it's just "old man shouts at clouds", I'll just ignore the language and move on :)