<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class="">I wrote this a few months ago, but we weren't accepting additive proposals. Now we're explicitly looking for something like this:<br class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="white-space: pre-wrap;" class="">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.</span> </blockquote></div></div></blockquote><br class=""></div><div>Memory ownership is about something slightly different than this. In the context of Swift, the model we’re looking for is:</div><div><br class=""></div><div>- 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.</div><div><br class=""></div><div>- 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”.</div><div class=""><br class=""></div><div class="">- 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.</div><br class=""><div class="">- 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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">If you have more specific questions, feel free to ask about it.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>