[swift-dev] Continuation-based versus nested-function-based materializeForSet

[Joe Groff]

> On Nov 1, 2016, at 9:23 PM, Slava Pestov <spestov at apple.com> wrote:
> 
>> 
>> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
>> 
>> - Does this help us with the nested dictionary CoW problem? `foo["bar"]["baz"] += 1`
> 
> My understanding is that this problem arises because we don’t have ‘optional addressors’. A dictionary lookup might return nil. If addressors had a way to return an optional wrapping a pointer, and optional evaluation supported this, we could do in-place updates of this kind. For Apple people: I have a radar that I think describes this problem (rdar://17509619).

I think our long-term goal here is to let the property definition fully control the `inout` access with a coroutine-like definition, something like:

var foo: T {
  get { return /*value for read-only access*/ }
  set { _foo = /*write-only access*/ }
  mutate {
    var tmp = prepareForMutation()
    yield &tmp // continue nested inout access
    reconcileMutation(tmp)
  }
}

This should let the dictionary implementation do whatever it needs to present a moved Optional value to the chained access. If Dictionary can't store Optionals directly inline in all cases, we ought to still be able to rely on enforced inout uniqueness to get away with moving in and out of a temporary.

-Joe