
Manifesto: Adding memory ownership to Swift - mpweiher
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032155.html
======
telotortium
A summary (from the Rust subreddit
[https://www.reddit.com/r/rust/comments/5unav5/](https://www.reddit.com/r/rust/comments/5unav5/)):
[https://gist.github.com/Gankro/1f79fbf2a9776302a9d4c8c0097cc...](https://gist.github.com/Gankro/1f79fbf2a9776302a9d4c8c0097cc40e).

~~~
Gankro
Hit me up with any questions y'all have.

~~~
solidsnack9000
The Swift ownership system doesn't address concurrency because a mutable
reference can be passed to a function, stored somewhere, and then passed to
another function?

~~~
Gankro
The major holes are: class fields, globals, and captures of escaping (non-
scoped) closures (which are basically class fields).

Although this system proposes dynamic checking for these cases, it's
explicitly not atomic checking. Atomic checking would be very expensive even
though most code doesn't need it. Also there's a general sense that java,
which does atomically guard all shared mutable state, has the problem that
these accesses are _defined_ but ultimately useless. Part of this is that
coherent updates require coarser locks.

~~~
solidsnack9000
Maybe for objects it makes more sense to be able to "own" the object as a
whole, if I am understanding you right. Still reading the Swift proposal.

------
jsolson
I'm at work and went diving into the doc looking for one specific thing. I
found it, but it turns out to be a put unfortunate.

[https://github.com/apple/swift/blob/master/docs/OwnershipMan...](https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md#deinit-
for-non-copyable-types)

> Swift is permitted to destroy a value (and thus call deinit) at any time
> between its last use and its formal point of destruction. The exact
> definition of "use" for the purposes of this definition is not yet fully
> decided.

For things like scoped lockables the last "use" must be well defined with
respect to the termination of the scope. Early deinit means you're still
unable to build something like C++'s std::lock_guard
([http://en.cppreference.com/w/cpp/thread/lock_guard](http://en.cppreference.com/w/cpp/thread/lock_guard)).

Consider:

    
    
        // dwizzles can be fizzled up to three times, but no more.
        class dwizzle {
         public:
          dwizzle() : count_(0) {}
    
          void fizzle() {
            std::lock_guard lock(&mutex_);
            if (count_ >= 3) return;
            ++count_;
          }  
         private:
          std::mutex mutex_;
          int count_ = 0;
        };
    

Obviously a silly toy, but the point is that we acquire the lock, we must hold
it until the end of the scope for correctness, and we want to ensure it's
dropped on early returns.

I hope any formal proposal coming out of this has a sufficiently strict
definition of "use" (or provides opt-in tools for building structs that
restrict the definition appropriately) to allow such constructions. It's much
nicer than having to always type something like:

    
    
        mutex.lock()
        defer {
          mutex.unlock()
        }
    

(apologies for any inconsistency in my C++ above -- the codebase I routinely
work in has its own mutex type and an equivalent scoped lockable -- I tried to
adopt the more standard version for universality's sake).

~~~
Gankro
The argument for Swift's behaviour is basically: very few things actually need
this guarantee, and it's bad for performance (or memory usage) for all the
other types to inherit it.

Personally, as someone who has spent a lot of time trying to manage the
safe/unsafe code boundary, I'm inclined to agree with you. Unsafe code in
Swift has an even scarrier subtle hazard: if the last uses of a value are
through an unmanaged handle, the compiler won't know and can free the managed
value before those uses. You need to insert a marker saying "please keep this
alive". Even worse: returning a value, after inlining, isn't sufficient to
establish a use!

That said, your lock handle example doesn't matter in swift today: you really
want a lock handle to be a struct, and structs can't have destructors. You
also want it to have move semantics, which don't exist yet. This proposal
suggests moveonly values that could adopt destructors (like Rust), and if
you're already adding an annotation for destructors, it's not out of the
question to add another one asking for "true" lexical destructors.

~~~
jsolson
Indeed, my point was that if you're going to add moveonly types with
destructors having a way to force lexically scoped lifetime has concrete uses.

That said, having that be optional opt-in behavior could be valuable from a
compiler optimization freedom perspective.

------
Tanegashima
Swift doesn't have memory ownership because your supposed to use
DispatchQueues for that.

The end.

People asking for this are the people not familiar with Apple's SDK. And btw,
DispatchQueues are also available in Linux, GCD has been ported to Linux since
the beginning, but neckbeards have been trying to avoid it at all costs
because it's Apple, and now they are complaining because Swift has been taking
the spotlight from Rust.

~~~
bsaul
I think this argument is the real justification :

"Memory ownership model: an (opt-in) Cyclone/Rust-inspired memory ownership
model is highly desired by systems programmers and for other high-performance
applications that want predictable and deterministic performance"

I think it could be used to _implement_ mechanism such as dispatch queues,
which are for now implemented in C.

~~~
Tanegashima
And what's the problem of being implemented in C?

~~~
coldtea
What's your problem with it being implemented in Swift?

Because you phrased your answer in an adversary tone (what with neckbeards,
people jealous of Swift "taking the spotlight" etc) as if there was some war
going on.

Plus the whole, "It will always only be dispatch queues, deal with them,
period" vibe I don't really care for.

I gather you are not an official spokesperson for the Swift team, and thus
qualified to make such a call?

If you read TFA, it's an Apple engineer that says:

"Memory ownership is a topic that keeps poking its head up here. Core team
members have mentioned several times that it's something we're interested in
working on. "

