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

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.

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 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.

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.

    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 => ...,
    }

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

Did you reply to the wrong post?

s/\$LANGUAGE/C/