[swift-evolution] [Manifesto] Ownership

[John McCall]

> On Feb 18, 2017, at 11:08 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> Hi John,
> 
> This is fantastic!  I’ve been eagerly anticipating this.  It looks very much as I was hoping it would.  I can’t wait to see this vision come to life!
> 
> You only show a mutating generator example.  Do you also plan to allow shared generators?

Yes; a generator yielding a shared reference would be used for non-mutating iteration.

> One topic you don’t touch on that feels related is the ability to use RAII and rely on deferred deinit to ensure an owned resource isn’t released before the scope exits.  I can imagine something like `defer let resource = MyResource()`.  It may also be interesting to support “defer only” types to force a compiler error where non-deferred use would be incorrect.  What do you think?

My intuition is the use cases for this that I'm aware of are really a mis-use of values.  You might design an API that way in C++, where destructors are really the only language mechanism for injecting code into a function "later", but in Swift I think you would want to use either (1) a generalized accessor (if the protected resource could meaningfully be described as a single value) or (2) a callback that explicitly scopes what happens with the resource.

So e.g. if you wanted a Rust-style mutex API, you could do it like so:

moveonly struct Locked<T> {
  var unlockedMemory: T { // probably not the best name
    read {
      mutex.acquire()
      defer { mutex.release() } // There are reasons why I think this needs to be in a defer, but we can talk about them when we get to the detailed proposals for co-routines.  I'm still looking for a better language design.
      yield actualMemory // Recall that 'read' yields a shared value, so this doesn't implicitly copy.
    }
    nonmutating modify { // 'nonmutating' is a misnomer, but it's an existing misnomer.  Setters are 'mutating' methods by default and normally demand exclusive access to self, but we don't need that here because we're dynamically enforcing exclusive access to the memory, so all we need is shared access, and this is how we express that.
      mutex.acquire()
      defer { mutex.release() }
      yield &actualMemory
    }
  }

  private var mutex: Mutex
  private mutable var actualMemory: T // Make this variable mutable even within nonmutating methods; whether that makes sense is the programmer's problem.  I didn't cover this in the proposal, because it's speculative, but it's useful for things like our nonmutating modify.  Lots of open questions here.
}

Or if you wanted a more C-like mutex API, you'd do it like so:

moveonly struct Mutex {
  func withLock<T>(_ function: () throws -> T) rethrows -> T {
    acquire()
    defer { release() }
    return try function()
  }
}

But I just don't see the motivation to try to do this by making a function return a C++-style lock guard.

Do you have a use case which clearly benefits from an exact scoping and really needs to be an independent value?

John.

> 
>> On Feb 17, 2017, at 11:08 AM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
>>> Hi John, would you mind creating a markdown document for this manifesto in https://github.com/apple/swift/tree/master/docs <https://github.com/apple/swift/tree/master/docs>? :)
>>> 
>>> 
>> Yes, it should go in the repository.  That commit is pending, but the in meantime, you can see the document properly rendered at:
>>   https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md <https://github.com/rjmccall/swift/blob/4c67c1d45b6f9649cc39bbb296d63663c1ef841f/docs/OwnershipManifesto.md>
>> 
>> John.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/3f5fee4c/attachment.html>