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. https://www.tensorflow.org/swift. 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.
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.
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.
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.
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.
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.