In that respect, it seems like function builders skipped that whole process. It's not that they're a bad feature, and similar facilities exist in other languages, but the fact that they were added to the language without a lengthy vetting process seems very out of character.
In a way I don't even know if it's really needed. I have a project which uses declarative code to achieve similar goals to SwiftUI, and you can get really close without function builders. For instance, you can write code like this:
var view: [View] {[
Foo(...),
Bar(...),
Baz(...),
]}
It's not quite as clean as the function builder approach, and it doesn't have all the same benefits (i.e. producing a typed result vs an array of protocol instances) but it's very easy to understand and doesn't require any additional language features.My theory is that since Google has been pushing Flutter aggressively, Apple needed to answer with a "modern" FRP-style workflow for iOS to retain its developer mindshare.
More generally, Apple's yearly splash model seems to dictate that teams either release or wait 12 months, if waiting is even an option at all. It makes me wonder how many Apple APIs would have been revised under a more flexible release model.
Would function builders have much impact on ABI stability? My assumption was that they are essentially just a front-end transform: i.e. the SIL generated from a function builder would be equivalent to writing it out "long hand" - the same way that Codables can essentially be thought of as the compiler writing out boilerplate Swift code for you.