I don't really have anything to say about Apple surprising us with this language feature, I think it could be a great addition.
I do have to say that the feature is extremely limited in it's current form. It's frankly not going to be very useful if we can't use switch statements or true for/while loops. I assume these are in the works, but in its current state it falls well below the hype being heaped on it at WWDC.
C and C++ are probably the only general purpose languages even in the next decades.
And Rust ist trying hard to find its niche - as for a replacement to the general purpose languages it lacks the progressive disclosure attitude.
I think the niche/domain Swift is in is not too bad actually. And who knows - maybe another one will be eventually found outside the Apple ecosystem.
Just as a sidenote in the context: Even though I quite like the actual outcome, the process which lead to SwiftNIO was indeed no different. There was a Server Side Swift Group for quite a while (1-2 years?), with people providing API suggestions and actual implementations. While at the same time Apple developed NIO in its usual secrecy, for roughly a year. It even participated in discussions well knowing that a replacement was in the works. When it was done, it got announced and the sssg work discarded and later reestablished around NIO/Apple (w/ some members not even really deploying NIO ...).
But if the stuff provided is good, why complain? ;-) Apple is putting a lot of effort and resources into Swift, other languages don't necessarily have that. The primary feature of NIO is not that it is open source, but that it actually works and is well designed.
Everyone is perfectly aware that Apple doesn't do such stuff in the open and that you have to expect being sherlocked.
I guess all I'm saying is that the NIO, and I think 4TF too, both have been developed "in a closed environment". And that wasn't a bad thing after all :-) (Contrast that with say SPM, which was developed in the open ...)
While we all know it, it's not a good thing, and not something we should readily dismiss as if it's merely "the cost of doing business". Apple might be putting tons of resources into Swift, but don't forget, they're investing in it because it's in their best interest (and of course, I have no problem with that).
But don't treat it like charity. For one, many people in the community spend loooooots of their own free time and effort to advance the Swift ecosystem. They deserve a level of recognition and respect that's higher than "oh here, we worked something in secret for a year so now your project is useless ... but it's free, so you should be happy and grateful".
As someone who spends a lot of time providing crucial OpenSource Swift packages (like cows) I'm very much aware of that.
I'd be more concerned if awesome contributions by the community would be proactively rejected (which I think has never really happened). I'm not so much concerned if Apple does complex, effort intensive, nice stuff and even allows the community to pitch refinements prior final release.
"oh here, we worked something in secret for a year so now your project is useless ... but it's free, so you should be happy and grateful"
If it is substantially better than the previous proposals? AFAIK few or no people complained about NIO for example. To the degree that it is even proposed as a good example for OpenSource-Swift as we've seen as part of this thread ;-)
(sorry, looks like I hijacked the thread, I just wanted to point out that how NIO came into existence is not that different, it is not a typical FOSS community project either)
I want to express how much I appreciate everyone's candid, thoughtful and passionate input on this thread. I think the discussion here has been very good.
Aside from the function builders feature (now being discussed) all of the language features that are used by SwiftUI have been either gone completely through the evolution process or are close to being wrapped up:
There's probably others I'm missing, but they all went through the evolution process. Even the priority of proposing SE-0254 was indirectly motivated by SwiftUI, although it ultimately turned out to not be necessary (but a good addition to the language nevertheless).
Property wrappers is an excellent case where the evolution process played a crucial role in shaping a feature. While the proposal hasn't completed the full evolution process, it has gone through a review and multiple rounds of pitches, and the Core Team had already decided and publicly stated that the feature was going to be eventually accepted into Swift. What's in Xcode 11 is a preview of a feature, and the evolution review process needs to focus on deciding the final details. Even the renaming of the feature from property delegates to property wrappers was an outcome of the evolution discussion.
Regarding functional builders, I think it's important to dispel a potential misconception that this has been sitting in a cask for an extended period of time awaiting some public reveal:
Function builders was not a planned “surprise reveal”. Function builders emerged as a fairly recent solution to a problem after lots of design iteration and trial and error.
So why is it function builders coming up now on Swift Evolution:
It was recently developed, and all evolution proposals require an implementation. A change of this magnitude certainly needs to be put through its paces to demonstrate that it works and is cogent and cohesive.
We (on the Apple side) also got very close to WWDC and had a lot of plates to juggle. At some point it was so close to WWDC that running the pitch before WWDC wasn't realistic. We were also hammering out the details for a proposal until very recently.
I think pretty much everyone — including the folks at Apple — would have preferred to have had time to bring this to evolution before having it in beta tools. That said, the tools are still previews of a yet-unreleased stuff and details can change. It also probably helps the discussion to be able to see how the feature is used by SwiftUI.
I think the following statement from @GetSwifty summarizes what's going on well:
If anything, a feature like this really needs the oversight of the evolution process to ensure the right short-term and longer-view decisions are being made.
It is true that...
The Core Team are the ultimate deciders in what goes into Swift
Many of the folks on the Core team work at Apple and were involved in the conception of this feature
... but it also remains true that the evolution process remains an invaluable part of the evolution of Swift and will play an important role in the evaluation of this feature.
No, SE-0257 is not part of the SwiftUI DSL. The component values in a function-builders DSL are grammatically statements; if you want to explicitly separate them, you must do so with semicolons, not commas.
We think function builders are a better language direction for multiple reasons, but the feedback to SE-0257 unquestionably shaped the direction we took.
I'd just like to show my support here. Like basically every heavy Swift user, I was super happy in seeing SwiftUI, but also surprised and a little concerned, because it seemed to clearly rely on either:
some "unannounced" Swift feature;
hacks and magic.
But I'm actually thankful that it's going to be about a new feature, developed internally over progressive iterations, and it's great to see an actual pitch and draft proposal, for discussing details and move towards the final shape of this.
To me it's extremely important that there's a motivated core team that ultimately decides what goes into Swift, which of course means both what doesn't go, and what goes no matter what: it helps keeping the language consistent and opinionated, and I don't see this as a restriction on what the community can achieve as a whole.
Similar to SwiftNIO and Swift-Log I see the Core Team as iterating on things and releasing them to the community. The fact that it was even released to the community for review is a sign of good-faith by the team to engage the community. Most folks have already said that they can't use it because it doesn't support iOS 12, so unclear why there is so much flack. Even if SwiftUI itself doesn't become open source, DSL as a concept can be used by the community to do great things.
I don't really mind the Core team deciding things unilaterally. Language design is not a democracy and shouldn't be. If anything, I think that sometimes too many people try to influence Swift in their own way, leading sometimes to inconsistent language design.
However, in this case, I echo @Max_Desiatov's concerns about the language losing focus. In order to introduce a feature like SwiftUI, it seems that so many low-level design decisions would need to be made first, that the risk of unduly rushing these decisions seems quite high.
To me (admittedly as a non-app developer), it looks like Apple is reprioritising important development resources in order to satisfy some marketing promises, instead of fixing and improving core issues with the language first.
But it's Apple's decision to make, just as well as it's every developer's (or company's) decision whether to want to invest in Swift.
Honestly I’m stoked to have some great new features announced to spark more interest in the Swift ecosystem!
My main concern is, if there are language features being used by Apple (E.g. in SwiftUI), I would like to be able to use them myself in order to recreate something similar or, if needed, “polyfill” the feature for other platforms. If that’s possible, I’m happy. Of course, open sourcing SwiftUI would be even better, but I don’t see it happening.
I just want to say thank you to all contributors from Apple and from the wider Swift community for your hard work on Swift.
Honestly, it looks strange for me to see a feature in the latest beta Xcode version which has not been reviewed in GitHub yet.
As for the announced features (@ViewBuilder and Combine), I am really scared of the evolution of Swift. Starting from pretty useful compiler annotations for Objective-C compatibility, complication flags, and some features like @discardableResult, we have reached a Java-style annotation, @ViewBuilder, applying to function’s arguments. Don’t you think there should be a more consistent solution? For instance, improving syntax for arrays, to return from the Swift UI stacks’ closures an array of views?
I love Swift and its way to make my code safe and easy to read, but adding annotations and using type erasure classes in Combine look like we are going to completely drop its unique features and make Java 2.0. Moreover using static methods for such operations is more about procedural programming, not OOP or POP.
I mean I think new features should improve and complement POP/OOP way chosen for our language.