I'm very much in the camp that doesn't mind breaking changes; of course we shouldn't be too cavalier about them either, but if a sound case can be made for why a breaking change is required, then we shouldn't be afraid to make the change either.
The biggest example that's impacted me in Swift 3, besides all the renaming, is probably the new Collection indexing scheme; while the previous system was functional enough in many cases, the new one is simply better, and takes a lot of burden away from the indices themselves to track minutia required for them to operate. It's been a bit of pain to transition some of my code, and I put a lot of time into working around the old system, but on the whole my code is now cleaner and more efficient. So yeah, if the choice is between a language that is willing to make breaking changes that improve the language overall, compared to one that will remain stagnant and struggle to improve, then I'm willing to suffer some broken code that needs tweaking every time; we have developer previews and now support for multiple toolchains to make this much easier to work with and to preview potential breakages and fix them in advance. Lastly, I'd say that even with version 3 fast approaching, Swift is still a very new language; some of its ideas were more successful than others, and some have been reevaluated in view of new features that overlap or replace them. I fully expect that in future there will be fewer breaking changes, but I think that trying to force that state too early is counterproductive, as it may restrict far more desirable improvements. > On 7 Jul 2016, at 14:16, Taras Zakharko via swift-evolution > <[email protected]> wrote: > > The designers of Swift have adopted a pragmatic approach to things: get a > language that can be useful practically quickly, then improve it as things > go. Its very Apple-like and I think it makes a lot of sense. We have a lot of > useful changes in Swift 3.0, but the language is still far from complete. > Recent discussions make it very obvious that some fundamental features are > still in flux or are misunderstood (e.g the function argument label > discussion), and the generics implementation has a lot of important stuff > missing. Freezing Swift now would mean suspending it in a beta state. > > So, no, a strong disagree with the premise of this thread from me. > > Best, > > Taras _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
