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
