> On Nov 2, 2016, at 11:38 AM, John McCall via swift-dev <swift-dev@swift.org>
> wrote:
>
>> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev <swift-dev@swift.org>
>> wrote:
>>> On Nov 1, 2016, at 9:23 PM, Slava Pestov <spes...@apple.com> wrote:
>>>
>>>>
>>>> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
>>>> <swift-dev@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,
Sorry, I obviously meant move-only (i.e. non-copyable) values here. I keep
making this mistake.
John.
> 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.
> _______________________________________________
> swift-dev mailing list
> swift-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
