Hacker News Reader

Comment by paxcoder | Hacker News Reader

Restricted to `.case(:else: breakelse))` in the conditional, there seems to be no advantage to this over optional chaining.

And allowing `breakelse` in the branch obscures control flow.

Disclaimer: I am a return/break/continue skeptic. I think they obscure control flow too.

View on HN

(Author) The advantage over chaining, at a compiler level, is that (absent compiler optimizations) you still save one branch. With chaining, you end up with a Maybe/Optional/whatever at the end of the expression, that `if` then has to unwrap separately. `breakelse` jumps directly to the else branch. That also makes it a bit easier to understand in the success case, imo, because you get rid of the error types immediately, you don't wrap them into a final outer optional type.

Optional binding can refine the type.

https://docs.swift.org/swift-book/documentation/the-swift-pr...

Yes, as I mentioned, it's like an `if` with multiple bindings, but I don't force intermediate variable names. That example is in the article. :P

edit: Wait, it's not in the article, I rewrote it and removed that section. My apologies! Anyway, yes, it's like that.

I'm not sure I understand what you mean by multiple bindings? With if-let, binding to the variable is conditional, and it only happens if all parts of the chain return an actual value. Otherwise, as soon as one returns null, a jump can be made to the alternative branch. Am I missing something?

Reply on news.ycombinator.com