4 ms·
But you have to know all of them to read other people's code. To answer your question: I would immediately get rid of guard. Also, I think the complexity and
by cloogshicer 6mo ago
But you have to know all of them to read other people's code.
To answer your question: I would immediately get rid of guard.
Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.
- willtemperley 6mo agoI'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming. internal should definitely go though.
- cosmic_cheese 6mo agoThe absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.
- iamcalledrob 6mo agoI think the ?: operator ends up being a decent alternative, e.g. // Swift guard let foo = maybeFoo else { print("missing foo") return false } // Kotlin val foo = maybeFoo ?: run { print("missing foo") return false } Unless there's a use case for guard I'm not thinking of
- cosmic_cheese 6mo agoIt’s a decent alternative, but to someone not familiar with the language what’s going on isn’t as clear.