[swift-evolution] [Proposal] Property behaviors

[Chris Lattner]

On Jan 23, 2016, at 5:58 PM, Curt Clifton via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Can the core team comment on the likely evolution of proposals like property behaviors that are separated into first steps and future work? That is, should we expect that some of the future work might be in scope for Swift 3, depending on the implementation of the first steps? Or is the hope to lock down the scope for Swift 3 sooner rather than later?

I’m not sure exactly what you’re asking here, so let me respond to several points that you might be asking :-)

- We generally prefer small proposals that stand on their own, which can then have other proposals built on top of them.

- I think that property behaviors is a strong goal for Swift 3, because we’d like to clean up lazy, @NSManaged, etc to get magic out of the compiler.

- I think we want a fully baked implementation of property behaviors for swift 3, but would be willing to subset out advanced features if it makes sense.  It doesn’t have to solve all conceivable problems and can be extended over time.

- Predicting what will end up in Swift 3 (e.g., “will we achieve our goals?") is inherently fraught with peril and cannot be done perfectly.  There are a ton of unknowns in design and implementation of any feature (e.g., how do you know how long it will take to implement behaviors when we don’t have a concrete design?), and new work gets added all of the time as we find new problems to solve and the community identifies new problems.  It is also impossible to predict what open source contributors will provide.


Part of the reason we have to say “no” to good ideas is that we are incredibly design and implementation bound.  We have high goals for Swift 3 as it is, but we aren’t 100% certain we’ll be able to achieve them (that’s why they are “goals”, not “certainty”).  I think that we’ve had a consistent approach with Swift 3, where we’re focused on fixing core deficiencies in the base language, fixing implementation issues and designing resilience features that affect ABI stability, while taking on small scope extensions to the language.  This has come at a cost of having to defer discussion on “large” extensions to the language that do not affect the core model (e.g. the memberwise init revamp) but I’m hoping that we will still get some of those for Swift 3. 

Overall, this comes back to a higher order philosophy about what Swift 3 is really about: it is about driving the next wave of adoption of Swift by even more people.  This will hopefully come from new audiences coming on-board as Corelibs + Swift on Linux (and other platforms) become real, SwiftPM being great and growing into its own, and the Swift language/stdlib maturing even more.

What does this mean looking forward?  Well, Swift 2 to Swift 3 is going to be an unavoidably disruptive change for code since Cocoa renamification is going to land, and we’re going to be building impressive migration technology again.  As such, we should try to get the “rearrange all the deckchairs” changes into Swift 3 if possible, to make Swift 3 to 4 as smooth as possible.  While our community has generally been very kind and understanding about Swift evolving under their feet, we cannot keep doing this for long.  While I don’t think we’ll want to guarantee 100% source compatibility from Swift 3 to Swift 4, I’m hopefully that it will be much simpler than the upgrade to Swift 2 was or Swift 3 will be.

-Chris