A roadmap for improving Swift performance predictability: ARC improvements and ownership control

[Joe_Groff]

@Paul_Cantrell

Just to check basic understanding: I take it that move(…) is a purely compile-time construct, and shows up in the emitted code only as an earlier release? (Presumably it can even show up as a noop if the receiver consumes the moved value?)

Yeah, move shouldn't have any runtime effect at all on its own; it should only have the compile-time effect of taking the moved variable out of scope, and as a side effect of that, allowing the bound value's lifetime to shrink to the new end of scope. That compile-time-only transparency should avoid pitfalls like the one @allevato mentioned of std::move in C++ occasionally defeating last-use optimizations if used improperly.

@Karl

I get that the move would be needed basically for diagnostics against introducing accidental 'deinitialization barriers', but I think it will basically become a staple for many projects. Basically every function argument will get moved out at its first use. I wish there was a way we could make this less intrusive, and less scary to newcomers.

That's a fair concern. Our hope is that the lexical lifetime rules strike a balance where obvious code like this still does the right thing without explicit moves, so move (or however we end up spelling the operation) will still be something most Swift developers don't normally have to think about. But at the same time, performance-constrained developers who must get hard guarantees of their code's behavior really need something that will make the compiler raise diagnostics if those guarantees can't be met, for the reasons Andy laid out.

@Karl

Additionally, since this is a performance manifesto: has any thought been given to a Rust-style lifetime system? For example, will I be able to create an Array of non-escaping closures (which itself becomes bound by the same lifetime), and pass that in to a function (which must obey that lifetime restriction)?

Or is the idea that move-only types will allow this somehow?

I think we will need move-only types to be able to fully compose types with move-only properties on the level of Rust. These proposals will get us closer to that point, at least, and many of them would be required to work with values and parts of structs and classes without requiring copies anyway, but the full composability in the type system won't be there yet.

@allevato

On the topic of memory model and performance predictability, one thing that I wish could be added to this discussion is immortal data , such as data stored in static data segments. Currently, the only way to achieve this in Swift—aside from some specific types like StaticString that explicitly produce it—is to do an optimized build, but the ObjectOutliner SILOptimizer pass is entirely unpredictable to the average Swift developer.

I think this capability will be a natural outgrowth of compile-time constant values. Once we've established what a compile-time-constant expression is, then it would be a natural next step to be able to annotate an initializer expression as being required to be a constant expression.

@allevato

Essentially, I hope we can avoid some of the pitfalls that C++ has, where trying to do what you think is "the right thing" ends up making things worse. For example, a C++ user new to move-semantics might think "I have a function that returns a large collection, but I'll return std::move(...) it so it doesn't make a copy!", but then they've gone and undone the return-value optimization. So while this philosophy is something I agree with:

@Andrew_Trick

It's much simpler to explicitly express the intent [...]. Then, if the compiler can't honor that intent, it will provide a diagnostic.

...it would be even better if Swift can do the performant thing by default without any explicit expression of intent; that's what would set its memory model apart from other languages like C++ and Rust.

It is my hope that Swift will still be able to continue to "do the right thing" by default in most situations. As I noted above, our design for move should hopefully avoid the pitfalls of move in C++ being able to accidentally defeat the desired optimization. It could well be in practice, people end up spraying move everywhere out of an abundance of caution, but I hope that they won't need to.

@Saklad5

My mental model thus far has been that a value’s lifetime may end starting when it is last referenced. Is it correct to say that that is still true, but has been joined by a guarantee that it will end when the scope is exited?

In practice, the guarantee that it will end before or at the point the scope exits has always been there. We are planning to introduce new barriers that limit how far back a value's lifetime may end, so that it not only includes the final use in source code, but also things like weak reference loads and memory accesses through UnsafePointer that tend to rely on the lifetime of other variables to get correct behavior.