Hacker News Reader

Comment by TooBrokeToBeg | Hacker News Reader

I'm still puzzled to why would a compiler allow assignment in an explicit conditional (outside of loop syntax). It's like a baked-in blindspot that most people just want to ignore for some reason. Some languages actually guard against this well enough (eg Kotlin) and say "don't". Even with guards in place, it's not all that complicated to work around in the edge cases where you might want to do it.

View on HN

Funny you should mention Kotlin; while I like the language a lot, I believe this particular feature would be of immense help in the following scenario:

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, the problem is: how do you access String field x in the first branch? The only way to do it now is to extract the methos call into redundant local variable, and then pattern match it instead of `foo()` directly as I did above.

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

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

In Rust and Haskell you can do:

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

One option is match statements. Great way to make this sort of inline assignment unnecessary

Could you please elaborate more on what you mean by match statements? Is it an already existing feature of Kotlin?

Ah, I guess `when` is literally Kotlin's equivalent of match.

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

I see; I agree that proper pattern matching would indeed solve that as well, as e.g. Scala does.

It's handy in C for guarding parts of the language, as you often have to check return values anyway.

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

Missing assingment.

    int success = NULL;

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

That will result in undefined behaviour if the value returned by malloc is greater than INT_MAX. If you really need an integer, use intptr_t. But, generally it makes more sense to just use a pointer.

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

Because assignment is an expression. It has nothing specifically to do with the position being a conditional.

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

> Because assignment is an expression. It has nothing specifically to do with the position being a conditional.

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.

The other partial fix is to stop allowing truthy conditionals. Only allow Boolean values and the only time you it wrong is when you’re assigning to booleans.

Why is assignment an expression and not a statement? Why should an assignment evaluate to a value?

Well, if you have the concept of Maybe/Optional, it's quite handy to have a conditional binding as control flow (as in Swift):

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

    if let value = myOptional {
        // Use value
    }

Read Tim Peter's essay on the end of the PEP 572.

It's very good.

Reply on news.ycombinator.com