4 ms·
Restricted to `.case(:else: breakelse))` in the conditional, there seems to be no advantage to this over optional chaining. And allowing `breakelse` in the bra
by paxcoder 3y ago
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.
- FeepingCreature 3y ago(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.
- paxcoder 3y agoOptional binding can refine the type. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/thebasics/#Optional-Binding https://docs.swift.org/swift-book/documentation/the-swift-pr...
- FeepingCreature 3y agoYes, 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.
- paxcoder 3y agoI'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?