“I'm basically giving myself a permanent vacation from being BDFL”

https://lwn.net/Articles/757713/

yeah, if you code on 20 years old compilers with no warnings. GCC 4.1 warns about this (with -Wall) and Clang 3.4 warns about this too, without any warning flag.

"Shooting yourself in the foot is your fault for not using a linter that detects accidental misuse of assignment!"

Depends on what you think the answer to "is programming an art or a science" is. People who build bridges are absolutely subject to "strong opinions" on how to build bridges. I am of the opinion that shipping software to others when under a contract without using all the facilities available to prevent problems - linting, static type checking, etc - should be considered at best a breach of contract and ideally criminal negligence.

Maybe it's a know it when you see it kind of thing. When the debate isn't killing people, it's potentially inconvenient extra coding by a developer, and to appreciate the immense social cost those debates can have.

Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.

You can require additional brackets around assignment if you use the returning value (or otherwise it's syntax error). They did that with the new one anyway.

Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fantasy.

You clearly never had exposure to a PHP codebase. If people can trip up, people will trip up.

You mean compiler right? The compiler should be warning for things like this, not relying on 3rd party tools.

So, yes, if you're using a custom compiler, you kinda are to blame for shooting yourself in the foot. Just use the official binaries!

Imagine you have a sealed class Foo, with `class Bar(x: String) : Foo()` and `Baz() : Foo()`.

Now, imagine you have a method, returning an object of type Foo: `fun foo(): Foo`

And you want to pattern match on the result of this method:

  when(foo()) {
      is Bar -> ...
      is Baz -> ...
  }

Now imagine Kotlin had that feature; then we could just do the following:

  when(foo = foo()) {
    is Bar -> foo.x
    is Baz -> ...
  }

Conditionals need an expression, and assignment fits the bill, so it works.

But c-style assignment in Python was never going to happen, not should it have.

What I'm thinking of here is Rust's match statements, which do give you the ability to make use of those intermediary values by making use of Rust's enum type.

https://doc.rust-lang.org/book/second-edition/ch06-02-match....

Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still mandatory

They only did it if the := is at the root level. The following is completely legal:

    if match := re.search(pat, text):
        `print("Found:", match.group(0))

    [y := f(x), y**2, y**3]

(Assume for the sake of argument it’s some more reasonable example like "if (x = re_match(foo, bar)) {...}")

At least the systems I've seen need a extra (()) around = to disable the warnings and notify the reader that you're not just comparing for equality.

Throwing warnings for "common code" would be uncharacteristic.

    if (auto x = re_match(foo, bar); x.has_value()) {

> In another study that examined injuries presenting to the ER pre- and post-seat belt law introduction, it was found that 40% more escaped injury and 35% more escaped mild and moderate injuries.[83]

I don't know how many bugs can use of all possible explicit typing and compiler warnings avert but I'd wager that it would be at least as high a percentage.

I feel like a lot of the resistance is from people who think this is somehow bad style, because it's associated with a source of bugs in other languages. The same kind of people will argue endlessly against having 'goto' in a language, even when it can clearly make for cleaner code (eat it, Dijkstra!) in some cases.

    if(malloc(10000 * sizeof foo) == NULL) {
      // Error processing
    } // No need for an else branch here.

No, but it has a lot to do with the way humans write code. This is the source of the bug, not the logic. eg Why bother having whitespace that the compiler can't use (typically)? Human readability.

The concession to not take into account human failing, is pathological.

    int success = NULL;

    if(success = malloc(...)) {
    }
    if(success = malloc(...)) {
    }
    if(success = malloc(...)) {
    }

As another counterexample let me give you "language tooling". For example, write a tool that generates a FFI from $LANGUAGE to C. Is it really so unimportant that $LANGUAGE is clean and simple and easy to parse?

    char* p = NULL;
    if (p = malloc(...)) {
      ...
    }

    guard let value = myOptional else {
        // Handle absence
    }
    // Use value

    if let value = myOptional {
        // Use value
    }

It's very good.

Not if you have a good Integrated Development Environment (or IDE for short)! That's an even better "program" than your brain, because it shows syntax errors and other warnings right next to your code. It will literally put little red squiggly lines right under `if (x = 1)` and show the file as red in your file explorer side-bar, and when you hover over this line it will give you a tool tip saying "this assigns a new value, it's probably not what you meant, I can either turn it into x == 1 or ((x = 1)), which one do you want?" That is the power of IDEs and they are amazing. We should consider them an integral part of writing code and not fight them or be afraid of them!

    match foo() {
        Bar @ foo => foo.x,
        Baz => ...,
    }

    x = stuff
    while x:
        x = stuff

But the best solution is probably to just drop the = as an operator altogether.

Did you reply to the wrong post?

    while true:
        x = stuff
        if not x:
            break

s/\$LANGUAGE/C/

https://pic.plover.com/knuth-GOTO.pdf

  Another motivating code pattern is the "loop and a half".
 
  It was once common for processing a file by line, but that 
  has been solved by making file objects iterable; however 
  other non-iterable interfaces still suffer from patterns 
  like:
  
  line = f.readline()
  while line:
      ...  # process line
      line = f.readline()
  
  or like this:
  
  while True:
      line = f.readline()
      if not line:
          break
      ... # process line

  Either of those could be replaced with a much more clear
  and concise version using an assignment expression:

  while line := f.readline():
      ... # process line