I definitely agree. With Swift 3, especially near the end, we had a bunch of changes that were rushed in because “we won’t have a chance to change it later, so let’s do it just in case”. I think setting these deadlines leads to worse choices overall.
That said, we do need stability so that we can start to build things that we know will last. I have ObjC programs which are years old and still work fine, but I have to update my Swift projects every 6 months to get them to compile. What I would like to see instead of these deadlines for the whole language is for parts of the language to be stabilized over time. That is each part of the language and standard library would be marked one of the following: • Unstable - This is in active development or is expected to have major changes soon. You can build things with it, but expect to have to update that code. • Pre-stable - We have a design that we think works, and only expect minor tweaks, but we need to see how it works in the wild for a while before we know it is correct. • Stable - This is a proven design that we feel comfortable baking in to the language. It has been tested in real world code and we are confident it won’t need to change in ways that break backward/forward compatibility. Then each API would have this listed in the documentation. I think that the most we should start things at right now is “Pre-stable” given the pending updates from generics, concurrency, etc… that will affect wide swaths of the language. For example, the new Arithmetic stuff would be Pre-stable because we think it will be our design, but we may have small tweaks once we see how it interacts with other API in the real world. Then if it works as well as we think it will, we can move it to Stable in the following release. String would be unstable right now due to the planned upgrades. Breaking things up like this allows us to focus and take time on each part… baking things in as we are confident that they are the right choice. It also allows the developer community to plan accordingly and predict which parts of their code will need to be updated. I kind of feel like we are lying to ourselves with the current system. Thanks, Jon > On Jan 23, 2017, at 10:40 PM, David Hart via swift-evolution > <[email protected]> wrote: > > Hello swift-evolution, > > ABI stability is an important feature which many Swift users are looking > forward to. If I understand it correctly, once it’s here, the Standard > Library becomes part of that ABI and only additive and backwards-compatible > changes can be done. Seeing how we are still heavily modifying the Standard > Library this year (Strings), wouldn’t it be wiser to let those changes simmer > under the scrutiny of the broader community of Swift users for a year before > we make it into the ABI? > > ABI compatibility is important. Some projects need it, but I think that most > projects (most Apple platform third-party applications) would only mildly > benefit from it. But I want to make sure the Standard Library has had enough > time to mature before we set it in stone. > > Regards, > David. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
