Hi Chris, Yes, I did read it again, subscribe to that strategy.
I’ve perhaps over-emphasized the importance of the impact back-breaking changes .. Still.. The subject title was a bit overloaded too. I guess it’s between two extremes: that is, between (1) really freezing it and (2) using Swift as a continuous "software laboratory” :o) neither would be OK, (as with all extremities)... thanks Ted > On 10.07.2016, at 00:20, Chris Lattner <[email protected]> wrote: > > >> On Jul 9, 2016, at 12:41 PM, Ted F.A. van Gaalen <[email protected]> >> wrote: >> >> imho and after releasing Swift 3.0: >> =================== >> >> Existing language elements should never be removed, >> (even if they are frowned upon, which occasionally is caused >> by aspects of subjective opinion, lack of experience and premature vague >> statistics, we’re human aren’t we?) >> and even if much better newer solutions are available. >> >> New language elements should be supplements, standing on their own, >> with the purpose of extending Swift, not as changes of existing code, >> thus leaving the older equivalents intact as not to break older source code. > > Ted, > > I recommend that you familiarize yourself with the goals for Swift 3, which > are described here: > https://github.com/apple/swift-evolution > > An excerpt: > > "The primary goal of this release is to solidify and mature the Swift > language and development experience. While source breaking changes to the > language have been the norm for Swift 1 through 3, we would like the Swift > 3.x (and Swift 4+) languages to be as source compatible with Swift 3.0 as > reasonably possible.” > > -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
