4 ms·
He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what h
by jmull 7y ago
He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.
- dmitriid 7y agoIt does make sense. Because SwiftUI creates special constructs for regular language features (if, foreach) despite those features, you know, being available in the language.
- jmull 7y agoIt doesn’t make sense because SwiftUI is a declarative language. I understand the confusion, since it uses Swift’s DSL feature and is tightly integrated with Swift, but it is distinct and has it’s own design that isn’t directly compatible with Swift’s imperative control flow constructs. Now, you can argue that Apple should have created a new imperative Swift-integrated UI framework, and if they had, it would be a good criticism if all the normal Swift control-flow mechanisms weren’t available natively. But the author and you aren’t objecting to SwiftUI’s declarative nature. BTW, If you manage to map all the kinds of loops, breaks, etc, into SwiftUI it isn’t declarative anymore. You’ve managed to go back from describing the UI in terms of “what” (declarative) to “how” (imperative). Since the author expresses approval of the declarative nature of SwiftUI and complains about it, I know he’s confused.
- dmitriid 7y agoNo. I, and the author, argue that nothing prevents Swift from having declarative foreach/if. SwiftUI already introduces severely underdesigned awkward structures to replicate existing behavior, and it shouldn't. SwiftUI's ForEach and If are ugly unnecessary hacks that replicate existing behavior and raise the question: why aren't other constructs there?