Apparently, it can be very hard to get things right at the first try, but I don't think it should become the norm to change decisions right after they were made.
I also have the feeling that formal acceptance often takes quite a long time, and maybe that is because people want to avoid amendments, or fear to oversee problems which possibly can't be addressed later because of stability concerns.
But imho at least for purely additive proposals, all this stress isn't necessary:
Just like we have deprecated API that shouldn't be used because it's going to be removed, we could have API that is experimental and should only be used by those willing to accept breaking changes.
Another possibility to improve Swift in a more informed way just appeared with the TensorFlow branch, which has some features that aren't in the official release.
Instead of integrating those asap, we could use the opportunity and wait for some real-world experience and change details accordingly.
Afaics, no one can really be sure what we will think about @dynamicCallable after someone actually tried to build interop layers for Ruby, Javascript and other languages, or implement "regular" callable types; maybe everything will fit together nicely, but it might as well be that we paint ourselves into a corner â and it could be that we just need a little bit of patience to know for sure.
+1 to the idea. But I think this might get complicated depending on how these experimental features would be vended. I could foresee these kinds of experiments to be in some sort of Experimental module, but we currently don't have a roadmap for how these other modules would be vended/evolved/etc.
Rustâs strategy of introducing ânightly-onlyâ features, and adding them to stable only when they have, well, stabilized is interesting. Iâm not active in the Rust community but I would imagine this results in less pressure to get all the details right from the beginning (which is next to impossible as youâve pointed out).
You also have to explicitly activate each of the experimental features you want to use, making them even more unintrusive to those not interested in them.
I could see something like this being a nice aid to the evolution process, with a proposal implementation being available in nightly toolchains for a while either before or during review, so people can try it out easily.
I'm not quite sure this would work well for proposals that don't introduce new API but change the language in some way. Essentially, both the changed and unchanged version would need to be included in the build and chosen at runtime, which could get messy
I could see this being shipped in the available toolchains. We could even issue a warning when a nightly feature gets compiled in release mode as an extra safeguard against people putting nightly swift in production w/o intending to.
I also agree here. Maybe this is what SE needs to reduce the overhead for proposals.
Without looking in detail at how Rust does it, here's how I imagine it:
As soon as general agreement on the usefulness (or possible validity) of a pitch was obtained in the forums, a nightly slot could be created for that proposal, allowing then for the implementation itself to advance, without immediately needing the attention of everyone.
Every time a nightly feature is close to pushing a new release, it's audited by someone in the core team (or similar) and then it gets merged to the main nightly repo.
After the team behind a nightly feature feels like it's ready to hit production, it's reviewed by its users to look for feedback. A minimum amount of actual usage is needed before it can be greenlighted. If it hasn't been used enough, it can be promoted in the forums s.t. more people know what the state of the feature is.
If usage feedback aprooves it, the core team reviews it and if all goes right it gets merged into the main swift repo.
There have been recent steps towards getting more hands-on feedback, with toolchains being provided during proposal reviews. I'm not sure a big change is needed here, and I don't really see any issue with follow-up proposals (which are essentially equivalent to any feedback process) that don't result in excessive code churn for people using release versions, but perhaps something like this could be formalised as one possible result of a proposal review, e.g. âAccepted pending feedback processâ. I say âone possible resultâ because I don't think it is required or desirable for all proposals.
As to how to structure this theoretical feedback process, the primary problem is how to get people to actually try things out and give feedback ahead of release. There are a lot of people actively using Swift 4.2 now because it's in an Xcode beta, but that might be too late for feedback/changes and too tied to Apple for people's taste. Some additive things could be provided in a SwiftPM package, though these are the sort of proposals that would benefit from starting as an external library, getting popular, and then going through the evolution process. This has been rare so far, probably because SwiftPM is young and missing some major features required for wide adoption (e.g. a package repository).
It's a tricky thing to design and it will be inherently difficult to get people to do serious work on top of things that may change or even never make it through approval. Limiting the scope of changes to small amendments like the ones in your example, and signalling it as âthis has been accepted in general, but perhaps needs some minor tweaksâ could help.
On this point I will note that if your goal here is to speed up the evolution process in any way, then adding extra feedback and gating steps seems extremely unlikely to do that. If some formal feedback process is valuable it will be because it reduces code churn for users and improves proposal quality, and this will be at the expense of the time from proposal to release.
There was some discussion back in January about the possibility of having an âABI-unstableâ subset of the standard library, for things we havenât yet ossified.
I think the original goal was that the standard library would be really small, only offering core functionality, and things which didn't need compiler support could live as 3rd-party packages with independent versioning.
Unfortunately I don't really see a big community of ad-hoc Swift packages today. The Random API, for instance, could easily have been implemented as a package to smooth some of its rough edges. Once we had a good API with lots of usage experience, we could talk about incorporating that in to the standard library.
Looking at my own experiences/environment when developing in Swift, I think the deficiencies with the package manager are the biggest hurdle to moving more language/stdlib development out in to the community and gathering better feedback about them.
... but that would possibly cause an endless discussion wether the library should be called Random or DefaultRandomNumberGeneratorModule ;-)
Imho something comparable to C++ Boost would be a fantastic way to speed up development, but apparently, there is no big support for such a concept in Swift
To not only point on issues Random might have, there's at least one other big topic that suffers from the same problem in a different way:
While the API for RNGs was decided (at least partially) blindfold, there has been lots of activity regarding container types - and none of those ideas became real proposals... the current stdlib proves that something like SortedArray, OrderedSet, MultiSet or LinkedList does not have to be in that prominent location, but at the same time, the complete lack of some very basic structures and algorithms feels odd.
Yes, this is an issue. However, there is a goal of introducing a standard package index. Which I think will solve a lot of the problems we have regarding these things. With a standard package index we as the community can start moving towards de-facto standard modules for things such as Collections and other helpful bits.
I agree with this. Features like specialized data structures should absolutely just be built in the community as their own small libraries, and we can decide from there as a community if they should be pulled in the standard library. If there's work that we can do as a project to make third-party libraries more viable, we should absolutely take the time to do it.
A few things then: iterate faster on SPM to make it feature complete and less boilerplate-y than it is now; integrate SPM into Xcode; host an SPM index from swift.org, like CocoaPods. Only then can you start realistically believing community libraries could become popular enough to ever be considered for inclusion with the language. Until that point, every time an Apple developer says that popular libraries will be considered for inclusion in some way, I point to the thousands of pods and open source projects with thousands or tens of thousands of installs and wonder what they're talking about, since it hasn't happened yet.
These aren't surprising things, this is open source programming languages 101 in the modern age. I wish Apple would stop being surprised that this sort of stuff is required for a language ecosystem to really take off. These have all been known since Swift was announced, and certainly since it was open sourced.
People have absolutely pointed at projects like that and proposed adding things from them into the standard library. I'm not primarily focused on library evolution, but I'm sure I remember us taking some of those. Of course that's not going to happen without a proposal, though.
I would absolutely love to see SPM support from Xcode.
I don't understand why you would think anyone is surprised about this. If you've read any discussion around SwiftPM since the project was launched then it would be clear that these are all planned and/or desired in some form. It's fine to gripe about the speed at which it is happening, or that the priorities differ from yours, but how does pretending nobody has thought of these ideas help?
Because Apple still haven't prioritized the implementation of such features, haven't changed the Xcode release cadence so we may actually be able to use these features anytime soon, haven't produced any libraries that could form additions to the language themselves, and still haven't provided any guidance as to how the community can possibly get such a library through the bike shed gauntlet, no matter their popularity. So it's not that I'm surprised nobody thought of these issues, I'm surprised anyone from Apple can say, with a straight face, that there's a process for getting popular open source project included with the language. So either they're surprised when people keep bringing it up, or they know what's wrong, and yet keep insisting there's an actual process here.
Ultimately I guess my point is that it should be clear that whatever process there is for getting third party features into the standard library, or as an additional importable library shipped with the language, it isn't amenable to actually working, hence it's continual failure over the last two and half years to do anything. The community needs actual guidelines that they can meet and a process that isn't just "make a proposal". Otherwise the suggestion shouldn't be "popular libraries could be considered for inclusion" but "If you make a popular library, spend some time writing up a proposal and defending your existing architecture and design, hear nothing from the core team, and maybe, maybe, if the bikeshedding isn't too bad, perhaps your popular library could be considered, but probably not". And then stop being surprised when no one does that and no library makes it through the process.
If Apple actually wants additional libraries and outside additions to the standard library, then there should be specific, separate rules that aren't just "use the typical process". Otherwise, the fact that these might be popular existing libraries doesn't matter at all, and you're just asking for people to do all the work with no actual benefit to anyone.
I see your points, and think there are valid concerns here.
I wonder if we have a chicken-and-egg issue here about inclusions. The process may not be worked out because there are no clear examples, and the assumption is it will go through review like current stuff until we find that lacking, and then adjust as needed.
The concerns you raise about how such a review takes place are definitely fair though. The nit-picky bikeshedding has held back Swift as much as it helped us, and is a concern when we are talking complete libraries, or anything beyond even a trivial addition.
Ultimately perhaps it would be good for the community to decide how it wants to promote this stuff, and then put their wood behind that arrow and set up the process or something, because I would be concerned no one tries until someone else has done it, slowing things down considerably.
It would be good to see Xcode integration and iOS support sooner rather than later. As the primary IDE and platform for Swift development, it at least appears like Apple isnât invested in this, and SwiftPM doesnât hold a hope of catching on unless we make it easy to do in their IDE, and even possible for the primary platform with active Swift dev at the moment.
I don't understand the reasoning behind the complaints:
Apple want it to be really easy to make Apps for their platforms
That is why they created and continue to invest in Swift (and Xcode, and the platform SDKs) - not just to be fast, but to be easier to learn and use correctly.
Other languages, and platforms which are based on those languages, have an easier time because they have dependency managers.
Dependency management on Apple platforms was (and still is) pretty poor by comparison. There's no simple first-party solution.
The very existence of the SwiftPM project indicates that Apple considers this an important hole.
What would you even want Xcode to do with a SwiftPM package? If I had to guess, at least I'd want a nice GUI to find 3rd-party packages and easily add/remove them from my project. Basically, provide a GUI for manipulating the Package.swift file, and delegate building the project to the SwiftPM build system.
Xcode's bread-and-butter is creating frameworks and GUI application bundles for iOS and macOS platforms. SwiftPM's Package.swift file does not support creating those kinds of products. There is nothing to integrate right now - at the very least, the package manager needs to fill those holes (and it's coming soon: Swift PM, Bundles and Resources).
