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

[John McCall]

> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
>> 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.

It's tricky, because if Dictionary is going to support non-movable values, then we also want the non-mutating accessor to be able to return a Borrowed<Optional<V>>, which it can't do if that representation has to be a pointer to an Optional<V>.  It can returned an Optional<Borrowed<V>> just fine, of course.

This relates to the earlier conversation we had about borrowed tuples.  We may have to make the representation of a Borrowed<T> potentially different from just a T*, and that really stinks.

John.