And why is that time not now? Maybe it was all broken last week .
"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.
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.
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!
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".
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.
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.
So...your argument is Apple should develop all of it's software in the open? Good luck with that
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?
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.
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.
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.
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
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.
I don't think that's a fair comparison. SwiftNIO is a cross-platform API for lower-level functionality. SwiftUI is an Apple project for Apple platforms that has zero (direct) effect on any other platforms.
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.
Respectfully, I think this is a massive overreaction. It's demonstrably the case that community feedback is taken into consideration, and proposals can arise from community members. Despite this, if those in charge want something to happen, it almost certainly will. This fact has never been a secret--the process was deliberately set up this way so things could actually get done.
Wondering about the fate of upcoming Apple frameworks if this feature was rejected is an interesting question, but realistically, it's very unlikely to happen because there's a demonstrable need for the feature and a strong motivation on the part of the language's designers. Those who might now judge Swift Evolution to be a pointless process were under a misconception. Nothing has changed; this is how things have been since the start. It's a vehicle for the community to influence and offer opinions, but the destination has always been chosen by those with approval/rejection powers.
Calling his comment a "massive overreaction" is itself an overreaction. Karl has a point. There is nothing wrong with Swift being Apple's language, but i currently don't see it transcend beyond that either.
It would be interesting to see how much Apple actually gains by open sourcing Swift. I would assume that 99% of the compiler's code is contributed by Apple employees and the evolution process is useful for validating ideas and gaining new ones once in a while.
The average user on this forum probably never contributed any real code to the repo and is here purely for the bikeshed I am guilty too.
For this reason, I think it's fair that some design decisions are driven by Apple. After all, they are the main sponsor of the project.
Aside from that, I love SwiftUI and my only wish is if Apple would open source that too and make it cross platform to work on Android. That would be huge.
Making SwiftUI open sourced from the start would also prevent discussions like this one since everything would be developed in the open. Especially since it's very similar to React and Flutter which are both developed in the open.
I'm interested in you elaborating on this. Do you mean the swift evolution community's best interest, do you think pursuing DSL is an actively harmful language feature from a technical perspective, or do you have some other feedback.
More information on your concerns may help for a rational, productive conversation.
Not to sound like an asshole, but what's the point? This stuff is implemented, announced publicly, and already shipped in the betas.
What sort of feedback are you guys looking for, and realistically, what kind of feedback would you be willing to act on? E.g. are API breaking changes on the table, or has everything been fixed now that it's announced?
I have a very similar feeling at times, so please let me elaborate on this, and I hope @Karl can clarify his point. This will probably seem long-winded, but please bear with me.
I initially was very excited when Swift was open sourced, and the goal of "Swift conquering the world" as Chris Lattner stated it at the time, made perfect sense. Swift strikes a great balance for me personally and it seemed that improving the cross-platform support would make it a real "language for the next 40 years" But recently, I no longer see enough people taking that goal seriously or looking in the broader context at how to achieve this.
There are also many small frustrations around the ecosystem and the overall process. I've already linked to not so great the experience with server-side Swift other people had above in the thread. The gist is that the developer tools are still not very usable on other platforms. SourceKit-LSP was supposed to fix this, but here we are, 5 years later after the language became publicly available, and it's still not possible to work on more or less real project outside of Xcode.
While working on the WebAssembly port of the compiler I found the compiler codebase very hard to work with, as compared to other compiler codebases, I've previously tinkered with Rust, PureScript, Babel transpilers. The amount of time you need to spend on making even a small contribution to the Swift compiler is currently enormous and requires expensive hardware to work on it comfortably, produce debug builds, set up the environment, dig up the documentation, brush up C++ skills etc.
Important enough: Swift is probably the only major compiler of modern languages that isn't bootstrapped. Scala compiler is written in Scala, Go compiler is written in Go, Rust compiler is written in Rust, Kotlin compiler is written in Kotlin, and only Swift compiler is written in C++.
I bet an important reason for this is the C++ barrier. Many people would like to contribute and participate more in the Swift evolution, but now the requirement is that you have to produce a working patch before a proposal is even considered. I sometimes find myself on Rust Forums and feel overwhelmed by the amount of fundamental activity going on. Rust Generics Working Group, RustWasm Working Group, the infrastructure feels vibrant and moving much faster than what we have for Swift, despite Rust having initially a much smaller mindshare and a very narrow niche.
All in all, the Swift ecosystem for the last few years feels stagnant to me compared to what you can se around. SwiftNIO and Swift4TF were really breakthroughs, but this probably isn't enough. I'm seeing plenty of people around me no longer considering Swift for their mobile apps, primarily because of Flutter and React Native, while Kotlin Native is moving fast too. I understand that there always be a niche for native apps, and there will be people who will use Swift for server-side no matter what. But currently I can only make a compelling argument for using Swift the language, but can't do so for the size of the ecosystem or the quality of the developer tools.
Also, there's the Swift patent thing, which I'm not going to elaborate on. It's been discussed on Swift Forums probably too much at this point, with no progress on that visible.
After all this, it's a bit frustrating to see SwiftUI and Combine, projects with the huge potential for the ecosystem, being released as closed source and with a suprise announcements of new language features that will ship in a few months just for a proprietary framework to be frozen in time for an OS release.
It no longer feels like the language in general has focus. What happened to move-only types? What's the plan for cleaner asynchronous code? I bet there's a lot of under the hood work going on, and I appreciate all of the hard work done by the compiler engineers. I hope this is only a feeling, and a lot of this stuff is easy to fix with more clear and open communication from the Core Team. Obviosly, no one is entitled to any changes in the communication, but I personally think that Swift as an open source project, and the major frameworks released for it, could benefit a lot from more transparency.
These days Microsoft seems to be like a massive open source contributor and I'm jelous of the .NET developer ecosystem, which we unfortunately we don't have in Swift. But I hope we could have it, if major frameworks for Swift were seriously considered to be open sourced. Without it, it all feels like an iOS bubble that's totally dependent on Apple's hardware sales numbers.
I sometimes feel ambivalent about this, but seeing that a lot of people shared similar thoughts in this thread and other threads, I decided to share it, thanks for reading!
.
I am guilty too.