Thanks for the detailed response :) My mistake, I was thinking more in terms of managing a user's expectations regarding ownership and avoiding retain cycles.
What you've described sounds great. I imagine it should only affect this proposal if the solution it provides adds additional checks for users accidentally taking strong references. On Sat, Jul 30, 2016 at 2:21 PM, Chris Lattner <[email protected]> wrote: > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution < > [email protected]> wrote: > > I wrote this a few months ago, but we weren't accepting additive > proposals. Now we're explicitly looking for something like this: > > Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory >> ownership model to Swift is highly desired by systems programmers and folks >> who want predictable and deterministic performance (for example, in real >> time audio processing code). More pertinent to the goals of Swift 4, this >> feature is important because it fundamentally shapes the ABI. It informs >> code generation for “inout", how low-level “addressors” work in the ABI, >> impacts the Swift runtime, and will have a significant impact on the type >> system and name mangling. > > > Memory ownership is about something slightly different than this. In the > context of Swift, the model we’re looking for is: > > - You can completely ignore memory ownership features of the language, and > get very far into development with Swift. This is in stark contrast with > Rust and Cyclone, which require you to grapple with it up front. This > means that in the Swift context, this will be more of a “power user” > feature, instead of essential part of the model. > > - You can choose to use the memory ownership features by adding extra > annotations, giving better performance and control over ARC. Right now we > have very limited options for avoiding ARC overhead in critical loops, > largely forcing you to drop down to unsafe constructs. We’d prefer the > model to be “you can add more annotations to your code to get better > performance, allowing the compiler statically verify correctness instead of > dynamically”. > > - Memory ownership control is an extremely non-trivial feature, which will > probably drive us to add first class move semantics and region types to the > language. This will also call for significant standard library > extensions. It will pay for this complexity by making it easy to ignore > the complexity if you don’t want it, and by the fact that the standard > library and other stuff can go much faster. > > - As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use > of these features, for code that wants to guarantee deterministic > performance. This is what enables the use of swift in realtime audio > applications, for example. > > While some initial brainstorming and scoping has been done in this area, > we’re far from having a concrete design. We have a few folks who are > experts at Rust that are helping contribute ideas and experience to this > though. > > If you have more specific questions, feel free to ask about it. > > -Chris >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
