> On Feb 18, 2017, at 11:08 AM, Matthew Johnson <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>> On Feb 17, 2017, at 4:50 AM, Adrian Zubarev
>>> <[email protected] <mailto:[email protected]>>
>>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
