Wednesday, April 8, 2020

Swift Initialization, SwiftUI and Function Builders: Called It!

Back in 2014, I wrote a post titled Remove features for greater power, aka: Swift and Objective-C initializers. In this post, I compared the IMHO insane language rules for initialisation in Swift (at the time 14 pages in the Swift book) with the complete lack of such rules in Objective-C, or Smalltalk for that matter.

Chris was so kind to leave a comment stating that my desire for simplicity was incompatible with some specific goals they had for the language. My response was that maybe those goals were incompatible with simplicity. It's a matter of priorities.

A prediction I made was that these rules, despite or more likely because of their complexity, would not be sufficient. And that turned out to be correct, as predicted, people turned to workarounds, just like they did with C++ and Java constructors.

Well, turns out I was correct beyond my wildest dreams: what are SwiftUI Function Builders if not a way to create/initialize complex object structures?

So I'll just come out and say that I called it. :-)

And while I obviously agree that a way to write down complex object structures is useful and important, and the mechanism is once again very clever, I will go out on a limb and claim that the pain that people are encountering now due to weird interactions with the language and type-system is not just due to an immature implementation and growing pains. Of course things will get better, but the fundamental problems of complexity, restrictions, non-obvious interactions with the type-system etc. are essential, not accidental, and therefore can be expected to be with us for good.

2 comments:

jjoelson said...

> what are SwiftUI Function Builders if not a way to create/initialize complex object structures?

To me the primary motivation for function builders seems to have been achieving a particular syntax for specifying SwiftUI views. Can you elaborate on why you think they’re about getting around initialization limitations?

Marcel Weiher said...

The problem here is that it is so tightly constrained and inflexible that it is not adaptable to new tasks.

Which is generally the problem with this approach to PLs. You bake current practice/patterns/conventions (see ObjC initialisation) into the language, you can't go beyond them without making changes to the language.

This was predictable. And predicted.