IMPORTANT: Evolution discussion of the new DSL feature behind SwiftUI

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?

2 Likes

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.

22 Likes

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?

1 Like

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.

2 Likes

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:

  1. X entity has an idea for Y use case in Swift they don't want to immediately announce
  2. Y is not currently possible with Swift, so X builds Z feature to support Y.
  3. X announces/releases Y with a custom flavor of Swift with required Z feature.
  4. X proposes evolution changes to support Z in Swift.
  5. Evolution process discusses and iterates on Z.
  6. Z is officially added to Swift, implemented faster due to X's foundational work.
  7. 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.

38 Likes

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.

6 Likes

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.

17 Likes

And why is that time not now? Maybe it was all broken last week :wink:.

"pure Swift Framework" in this context is (I'm guessing) referring to Swift-only, meaning no Obj-C. And i'm sure the intention is to use standard Swift features as soon as they are available. However that's technically Apple's concern, not Swift's.

Keep in mind that SwiftUI is an Apple feature, not a Swift feature. Although Apple building these features is similar to them saying "this is the new release of Swift", it isn't the same. To my knowledge they have not said this. My guess is the team wanted to build something that worked like SwiftUI, and only added the features necessary to make that happen.

I disagree. A language fork would be intentional and long term. This is clearly intended to be merged as soon as possible and it's also clear that, again, the functionality used in SwiftUI will exist in Swift at some point. Yes this will require Apple to update their framework to support it. But that is also likely to happen with the SE process.

6 Likes

I would love that! It's also (IMO) not relevant to the issue. It's Apple's framework and they can do what they want with it. However it seems entirely possible for someone to build a cross-platform implementation that's compatible.

4 Likes

Thank you for bringing this up to the Swift evolution so quickly. I honestly don't know how else this could have been done better. The whole thing seems like a skunkworks project which is awesome!. I know the team brought up some features like opaque results types and property wrappers to swift evolution which I thought was great. Of course I also thought "All of these features are making swift more complicated and I cant see a clear usecase". :) Congrats on all the work that is making this possible. Keep up the great work!

5 Likes

We don't know precisely for this reason, the framework itself and the language features were developed in a closed environment without any community feedback. Please note that if SwiftUI was open source we wouldn't have any of these problems, there would be no need for a surprise announcement, the architecture of the framework and the language features could be discussed in the open and there would be less pressure to ship it in a specific version of any OS. Users of SwiftUI could just stick a dependency to its specific version in Package.swift, as they do for any other SwiftPM-compatible package. And we know that this can be done, SwiftNIO is the best possible model here. Both in terms of the open development process, and the fact that it isn't tied to the iOS release schedule.

For me personally, it's clear that we might have a different version of Swift shipped in Xcode 11 than the Swift 5.1 release I'd use on Linux. If it looks like a language fork, works like a language fork, it's a language fork for all intents and purposes. It might be accepted and merged upstream some day, but until that's done, I'm not looking forward to seeing more libraries on GitHub that only work with "Xcode Swift" instead of "just Swift usable on any platform".

2 Likes

I would be extremely surprised and perturbed if they differed as much as in the actual languages features/capabilities shipped. I don't recall any previous OS versions of Swift differing like this. At least with regards to the base language. Now the whole Foundation/other frameworks is a different story that has been debated before.

2 Likes

It would be no different than several other features that have been "available" publicly, but not supported to use and prefixed with _.

This feature will exist in the compiler in some form until it's accepted and refined to be publicly used. I highly doubt it'll be akin to the situation with Foundation where using it unexpectedly will cause crashes / compile errors on Linux.

1 Like

So...your argument is Apple should develop all of it's software in the open? Good luck with that :wink:

They're bringing the features they're using to develop their software to Swift. That's exactly what I would want from anyone working with Swift. The point at which they reveal said work is their decision. Not the community's.

Isn't this is already true? e.g. @objc and any NS APIs. If anything doesn't this get us closer to a unified design with a UI framework that doesn't require Objective-C?

8 Likes

Oh sure, but that's my point here, if we have 100% certainty that these features will be shipped in both Xcode and Swift 5.1 for Linux this fall no matter what, even if they are rejected through Swift Evolution, what's the point of Swift Evolution then? Or are we 100% sure they will be accepted? Again, what's the point of the evolution process if it's predetermined? My points are very much in line here with what was posted in the beginning:

AFAIU, the actual Objective-C support is still in the OS version of the compiler, but dependent on an objc runtime. I recall that at one point the author of GNUstep was going to take a look to see what it'd take to bridge from it on Linux. Obviously that went nowhere, but the capability to have Obj-C bridging on linux is there.

1 Like

Like I said earlier, it's a misconception to think SE decides the outcome of proposals. SE does not in of itself decide the evolution of Swift. We are merely a guiding voice to the core team. It is them who have the final say in what goes in or not.

13 Likes

No, that's not my point. I don't think I said that anywhere. I'm only comparing the development process of SwiftNIO and SwiftUI and impact of both on the community.

Both @objc and property wrappers can't be used on Linux. If/when property wrappers and the DSL proposal get accepted/shipped on all platforms, that would be true, but it isn't at the moment.

Like I said

In any project, OSS or otherwise, there will be a team with veto/approval power. These features, just like any others, will evolved through the SE process and turn out better than if Apple would have just released the feature themselves. For that matter they already have. e.g. the naming switch to propertyWrappers

5 Likes

I think it would be possible that some kind of DSL mechanism that is comptible with the needs of SwiftUI will definitly ship no matter what but the details can still be discussed.

1 Like
Terms of Service

Privacy Policy

Cookie Policy