Most active commenters
  • korijn(4)

←back to thread

317 points est | 14 comments | | HN request time: 1.244s | source | bottom
1. korijn ◴[] No.17449188[source]
It feels like we are repeating a mistake the PHP community made years ago. PHP supports assignment in expressions, and the community seems to avoid its use. There are plenty of examples of stackoverflow questions and answers where the problem is caused by coders overlooking an assignment in an expression. You just don't expect assignment to occur in an expression, and its visually similar enough to gloss over it.
replies(4): >>17449245 #>>17449289 #>>17449406 #>>17450205 #
2. Ar-Curunir ◴[] No.17449245[source]
On the other hand you can assign within expressions in Rust, and it's generally not been an issue that I've seen anyone complain about. However, that might be because the type checker usually catches you if you're making a mistake; assignment/variable binding return the type `()`, which doesn't work inside ifs or whiles
replies(2): >>17449392 #>>17453679 #
3. johannes1234321 ◴[] No.17449289[source]
Before there were iterators in PHP `while ($row = fetch_row())` was the only sensible iteration pattern.

Before there were exceptions `if ($result = query())` was the cleanest error-checking approach.

Also PHP didn't invent that syntax in any way, but followed C (in the end early PHP was a simplified C created by a C programmer) it only later git higher level constructs making this less needed.

4. sametmax ◴[] No.17449392[source]
In PHP, the "$a = 1" and "$a == 1" look a lot like each others. In rust, you would use "let a = " which removes the ambiguity.
5. sametmax ◴[] No.17449406[source]
In PHP, the "if ($a = 1)" and "if ($a == 1)" look a lot like each others.

In the Python version, the new "(a := 1)" will stand out compare to the canonical "a == 1" as the ':' and '()' are unexpected here, and scream that it's not regular if test.

replies(3): >>17451677 #>>17451814 #>>17453916 #
6. werdnapk ◴[] No.17450205[source]
In Ruby, this idiom is fairly common as far as I can tell. Perhaps rubocop (code analyzer) warns against it's usage, but I'm not sure.
replies(1): >>17451780 #
7. dvlsg ◴[] No.17451677[source]
Same problem in Javascript. There's actually a yoda lint rule that encourages you to write your code like (1 === a) instead, so you don't accidentally make that mistake.
replies(1): >>17453341 #
8. korijn ◴[] No.17451780[source]
There's this: https://github.com/rubocop-hq/ruby-style-guide/pull/65
9. korijn ◴[] No.17451814[source]
I'm curious to see how it will pan out in practise, but I'm not getting my hopes up.

I made a flake8 plugin to forbid assignment expressions:

https://github.com/Korijn/flake8-assignexp

Will be released once python 3.8 is out and I can test it.

replies(1): >>17453563 #
10. makapuf ◴[] No.17453341{3}[source]
I hate Yoda assignment in C. Does no good when assigning to variables. I think it's better to use the weird (on purpose) ((x=13)) and forbid x=13
11. geoelectric ◴[] No.17453563{3}[source]
That seems unnecessarily reactionary, but ok. I agree with the post you're responding to that having a completely separate token for inline assignment fixes the majority of issues that have historically come up with it (which mostly come down to forgetting an = in the ==). Might be worth feeling out the trajectory of the feature before proactively banning it from codebases you control.
replies(1): >>17455994 #
12. marcosdumay ◴[] No.17453679[source]
That's equivalent to the Python's (=) operator, that return None. What Python got now is a different (:=) operator, that behaves like the assignment in C.
13. thomasahle ◴[] No.17453916[source]
The '()'s are not always needed though, as in the PEP examples `(y := f(x), x/y)` and `(x := 0, x := 1)`.

The alternative `f(x) as y` syntax looked nice to my eyes, and doesn't introduce new symbols. However I'm sure they are right, that it would have bad corner cases.

14. korijn ◴[] No.17455994{4}[source]
You're right. Like I said, I'm curious to see how it will pan out, but I'm not getting my hopes up. I'm just not a fan of this new syntax. :) IMHO null-safe navigation operators like ?. and ?[] are much more important to have.