2 ms·

It's the difference between (await (await foo).bar).baz and foo.await.bar.await.baz -- which do you want to write?

int_19h 2y ago
In general, the rule of thumb is that prefix and postfix operators don't mix well in a single expression - order of operations is confusing, and reading the code requires going back and forth to follow it. 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.)
wruza 2y ago
Is this something you write often in Rust? A promise returning a struct with a promise returning a struct with a promise. Although I agree that await could use some precedence like new in javascript: new types.Date().toJSON() // fine await readdir(…).filter(…) // oops I’d rather parenthesize what I’m awaiting in complex cases than awaiting just everything that follows.
spacedcowboy 2y ago
> which do you want to write? Neither, honestly. They both look terrible.
d0mine 2y ago
In Python, there is no .await. But I can't remember seeing (await (await for).bar) ever--meaning it is very unlikely. It is usually written as: bar = await foo() await bar.coro(*args) Some people hate that calling functions of different colors is syntactically distinct. On the contrary, I find it beneficial that suspension points stand out. Unlike code with preemptive threads that is much harder to reason about.

In general, the rule of thumb is that prefix and postfix operators don't mix well in a single expression - order of operations is confusing, and reading the code requires going back and forth to follow it. 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.)

wruza 2y ago

Is this something you write often in Rust? A promise returning a struct with a promise returning a struct with a promise. Although I agree that await could use some precedence like new in javascript: new types.Date().toJSON() // fine await readdir(…).filter(…) // oops I’d rather parenthesize what I’m awaiting in complex cases than awaiting just everything that follows.

spacedcowboy 2y ago

> which do you want to write? Neither, honestly. They both look terrible.

d0mine 2y ago

In Python, there is no .await. But I can't remember seeing (await (await for).bar) ever--meaning it is very unlikely. It is usually written as: bar = await foo() await bar.coro(*args) Some people hate that calling functions of different colors is syntactically distinct. On the contrary, I find it beneficial that suspension points stand out. Unlike code with preemptive threads that is much harder to reason about.