Those of you watching Apple's WWDC keynote today and introduction of SwiftUI likely observed a new enhancement to the Swift language in the form a DSL that could be used to build a UI in code.
This is a feature that has not been discussed on Swift evolution. The work on that feature has been very iterative with lots of experimentation. Those of us involved in that work wanted to make sure we had a design we were happy with before taking it back for discussion with the community. Further, while the feature is general purpose, adding it to Swift is easier to motivate and discuss the details with a compelling and concrete use case like SwiftUI.
@John_McCall and @Douglas_Gregor has written up an evolution proposal document that describes the language feature. The pitch thread can be found here:
Speaking on behalf of the Core Team, here are the next steps to discuss and review the feature:
The Core Team would like to run a formal review of the feature soon.
Before that review, we'd like to use the pitch thread for general discussion and questions about the feature.
While Apple has embraced the approach as part of SwiftUI, the evolution review is intended to have a real and tangible impact on the shape of the feature itself.
The best way to understand the feature is to try it out: the Swift compiler in the Xcode 11 beta implements the proposed feature, and the compiler implementation is also available in a pull request against the Swift repository.
(Context: this was originally posted on the Function Builders thread, but was moved here with my permission)
Meta question:
This is posted as a [Pitch], but given that this is being shown off at WWDC with videos and sample code and documentation, there's a heavy implication that the Core Team has "signed off" on this feature already, even though this thread is the first the community has heard of it.
Is it possible that the feedback from the community would cause the Core Team to reject this proposal?
If it is possible for feedback to cause the rejection of this idea, what would that mean for SwiftUI?
If it is not possible for feedback to cause the rejection of this idea, then what's really the point of going through the pitch + proposal process at all? And what does that mean about the claimed community-driven Swift Evolution process?
In every pitch or review that I was an author, or have participated in as a reviewer, there has been useful information generated and then incorporated into the design beyond a pass/fail bit. I'm interested in hearing the answer to this question too, but I think you are presenting a false dichotomy.
I get what you're saying, that reviews can incite change in proposals. However, in all those proposals, there's the understanding that no matter how good the review goes, the Core Team can still reject the proposal.
Is that possible in this situation? Is there any possible future in which this feature can be rejected?
Right, but an important piece of information is that the accept/reject is given to something different than the original pitch: an improved or revised version. Sometimes one big feature is split into a handful of smaller ones with other parts deferred as future work. Sometimes future work gets pulled in because an unanticipated use case arises that requires it be designed out.
I have no knowledge that pertains to this specific situation. In general, I see no reason why it couldn't. A vendor of Swift can support an additional language mode for their domain, e.g. Swift para TensorFlow (no modo de arquivamento) | Swift for TensorFlow. This happens frequently in open source projects, and the best ones find ways to incorporate commonality (or even the entirety) into mainline.
i don't really care about whether an apple-driven proposal can get vetoed by the community, since we never really had that power to begin with (core team has final say anyway, and everyone could oppose it and it could still get accepted), i'm more worried about arguably flawed features getting shipped from lack of community oversight.
so that it doesn't seem like i'm dragging the core team in any way, i'm going to use as an example my own proposal SE-0243, Codepoint and Character literals, which had a lot of Apple-employee supporters, but ran into community opposition, which is why it got rejected. if the proposal wasn't submitted to community review, certain people here, who know who they are, wouldn't have gotten a chance to write so much criticism of it, and it probably would have passed without much notice. I personally would have been happy with that outcome. but i also know there were other people who thought SE-243 was seriously flawed and didn't want to see it in the language. and now we are basically admitting that the approve/reject outcome can be different depending on whether the community as a whole is consulted before enacting a proposal, and i don't know if that's such a good thing for the ecosystem as a whole.
Personally, I think Apple and the core team are burning a lot of the goodwill this project used to have. I don't trust that they have the language's best interests at heart any more.
I find it hard to consider Swift a language for the next 40 years. It's a vehicle to deliver whatever new features Apple wants in their next OS release. I used to be a big proponent of the language at my company, but I've since recommended that we stop investing in Swift (a while ago). Now it's just our iOS UI language, which I suppose is just as well really.
I’m going to leave a lot of this for Ted, but I want to underline something I said in the proposal: it has always been a goal for Swift to enable libraries that feel clean and fluent at the point of use, and the team has always felt that there was a place for eDSLs in Swift. Three days after we announced Swift, I got up on stage at WWDC and spent ten minutes explaining how you could use various features in Swift to build a nice eDSL for writing text adventures; of course that was expository, but it was also earnest: if these things make your code better, if they solve problems for you without creating bigger ones, then you should use them and not feel ashamed. I think we’re all aware that that’s not to everyone’s taste, but it’s part of our basic design philosophy, not something being forced on us by political demands.
It is true that various members of the Core Team have been involved in working on the proposed feature before today, and as such, have formed some opinions about the shape of this feature. There was a lot of experimentation and iteration on the feature — with some blind alleys that were later abandoned — which is the main reason this feature is coming to discussion with the community now.
For context, the Core Team has generally supported directions of this nature in the language since the inception of Swift. @John_McCall makes a good point that we talked about using Swift for DSLs in the WWDC where Swift made an appearance:
In every proposal, but especially a proposal of this nature, the details do matter. Like in any language discussion on Swift Evolution, the community's involvement is an important part of reaching good decisions for the language and the community. A feature like this can also open up many important questions not just about the feature itself, but the broader design space.
The Core Team does not reject proposals arbitrarily — so I don't believe it's a case of "no matter how good the review goes". If the Core Team rejected proposals for no good reason then it would not be serving its function. Decisions that go into reviewing proposals incorporate a wide array of signal, and sometimes that signal reveals important concerns even if, generally speaking, everyone (including the Core Team) is in favor of an idea. Details really do matter, and the Core Team's role is to act as stewards that can balance the the various at factors at play when it comes to making actual decisions about the language.
My suggestion is that we see how the technical discussion goes and go from there. That's how we conduct every language discussion. Generally speaking everyone involved with Swift has tried to make good choices for the language and project since its inception. That hasn't changed.
The Evolution process has been and remains an important aspect in evaluating and clarifying designs and proposals. While members of the Core Team familiar with the proposal are generally in favor of it, the Evolution discussion remains of great importance. Let's take the discussion to @John_McCall's pitch thread, and see where it goes.
Would it be accurate to say that if the proposal got rejected, Apple would still use the feature for SwiftUI, but it would be "private" in the sense that it exists as a compiler feature exclusively for that and other development Apple will want to do with DSLs? And if the proposal is accepted, it would become a compiler feature available in the general language so that anyone using Swift could use it?
I think it's a fair bet to say that the function builders proposal will not be rejected, same as with property wrappers. It could be returned for revision, but it's most likely not to be rejected. We as the community can suggest tweaks or improvements to the design of the feature, but the feature itself is one explicitly from the core team and Apple.
It seems that a lot of people have the misconception that Swift is a language exclusively designed by the community. This is not true. We the community are simply a voice that can guide or propose improvements to Swift that the core team can take into consideration. But the fact remains that Swift's design is still decided by the core team.
True, I don't think the proposal will be rejected, but is it possible there could be syntax differences that the community proposes and that would affect how SwiftUI is written?
I might be confusing what you're asking here, but I'll answer what I think you mean, and what I assume still holds true WRT Swift's evolution.
It's entirely possible that some aspects of the function builder feature will be tweaked during a review, and any of those tweaks would require some changes to SwiftUI, since it builds on this language feature.
However, one of Swift's goals is to avoid dialects of Swift popping up. Even the Swift for TensorFlow project has the goal of upstreaming most of their automatic differentiation work into the master branch. Taking that into consideration, I don't think we'd see some split where Apple-vended Swift has a slightly different implementation/behavior for function builders than the open source version of Swift.
Analysis/context:
I'm a bit surprised at some of the blowback as this is exactly how I would expect this type of thing to work. Not just with Apple's development, but any other entity whether it's Joe Shmoe or TensorFlow:
X entity has an idea for Y use case in Swift they don't want to immediately announce
Y is not currently possible with Swift, so X builds Z feature to support Y.
X announces/releases Y with a custom flavor of Swift with required Z feature.
X proposes evolution changes to support Z in Swift.
Evolution process discusses and iterates on Z.
Z is officially added to Swift, implemented faster due to X's foundational work.
Y merges the official changes resulting in a feature that (ideally) works better than X's original version.
The complicating factor is in this case X entity (Apple) also ~owns the primary development of the language.
Yes, this can understandably be seen as a conflict of interest. However the history around Swift is relevant. Even when Swift was closed source it was clear the community's thoughts and feedback around the language had plenty of sway within Apple. E.g. the incredible amount Swift changed between it's first beta 5 years ago and the 1.0 just a few months later. AFAIK there's little evidence to say this attitude has changed, and plenty of evidence to the contrary, e.g. the very existence of this forum and thread.
Opinion:
Seeing SwiftUI with all these new features may be a bit jarring given many of them have/are seeing evolution discussion. However I'm unsure what the alternative would be. SwiftUI is very exciting to me, and I hope to start using it ASAP. Waiting for the full evolution process to take place would no doubt add months of waiting, delaying getting it into the hands of developers which IMO be a mistake. The functionality of SwiftUI seems inevitable and apparently an original goal for Swift.
The changes most likely to occur in SE are implementation details and/or, at the worst, fix-it-able things like name changes. So why wait?
Even with a worst case scenario of the changes facing massive community opposition, come September I would much prefer SwiftUI's release to it being delayed for months/years. Even if all the new features were locked out of the language generally while the changes are finalized.
In my opinion, the best alternative would be to announce these pitches as soon as they were ready, and to go through the usual evolution process for the community to discuss these features, without any surprise reveals at the WWDC keynote. If these weren't ready to be merged, then it would make no sense to build any "Swift-only" frameworks on top of these features. Otherwise the statement "SwiftUI is a pure Swift framework" would not be true, it is at the moment "a framework that uses Apple's flavour of Swift".
Now we see that either way these features will ship by September 2019, which is we can safely bet is the release date for Swift 5.1. Which, by the way, is dictated solely by the iPhone and iOS 13 release schedule. Let's hypothetically consider a scenario that due to a pushback from the community, the proposals aren't accepted by that time. This means that we'll have a flavour of Swift released with Xcode 11 with some features of that used in SwiftUI for iOS 13. It's highly like that SwiftUI API for iOS 13 will be more or less frozen until iOS 14, which means that those language features will be frozen too.
I totally understand the opinion that SwiftUI has to ship ASAP in whatever state it is. Unfortunately, Swift's ecosystem is already massively fragmented on other platforms. Consider a fresh post in a thread about server-side Swift:
Please consider that if Swift features required for SwiftUI are going to be shipped in September 2019 without going through a proper evolution process, with what would basically amount to a language fork, things would only get worse for other platforms. I competely support replacing UIKit and AppKit with something more modern, but this should not come at the expense of the ecosystem and the community as a whole, and cause even more fragmentation than we have now.
In fact, I would strongly advocate for SwiftUI to become open source and cross-platform. The sentiment I'm seeing around from some developers is like "So can we drop React Native and start using SwiftUI soon? Ah, it doesn't support Android? Ok, never mind, I'm staying with React Native and JavaScript".
Now granted, an API-compatible implementation of SwiftUI could exist for other platforms in the future, but making the language fragmented across platforms would make supporting much much harder.