> On Nov 1, 2016, at 3:32 PM, John McCall wrote:
>
>> On Oct 31, 2016, at 12:22 PM, Joe Groff via swift-dev
>> wrote:
>> We currently abstract over mutable property accesses using what I’ll call a
>> continuation-based model–the materializeForSet accessor is called before an
>> inout access,
> On Nov 2, 2016, at 11:38 AM, John McCall wrote:
>
>> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev
>> wrote:
>>> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote:
>>>
On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
wrote:
- Does this help us with the
> On Nov 2, 2016, at 11:38 AM, John McCall via swift-dev
> wrote:
>
>> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev
>> wrote:
>>> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote:
>>>
On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
wrote:
- Does this
> On Nov 2, 2016, at 9:05 AM, Joe Groff via swift-dev
> wrote:
>> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote:
>>
>>>
>>> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
>>> wrote:
>>>
>>> - Does this help us with the nested dictionary CoW problem?
>>> `foo["bar"]["baz"] += 1`
>>
> On Nov 1, 2016, at 9:23 PM, Slava Pestov wrote:
>
>>
>> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
>> 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 ‘o
> On Nov 1, 2016, at 11:00 AM, Jordan Rose via swift-dev
> 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 addr
> On Oct 31, 2016, at 12:22 PM, Joe Groff via swift-dev
> wrote:
> We currently abstract over mutable property accesses using what I’ll call a
> continuation-based model–the materializeForSet accessor is called before an
> inout access, and returns a continuation callback that must be called wh
> On Nov 1, 2016, at 11:00 AM, Jordan Rose wrote:
>
> I like the idea; it makes more sense to me than our current model (which
> feels more like a plain callback than a continuation to me). Some things that
> occurred to me when reading this:
>
> - This seems like it'll be much simpler to che
I like the idea; it makes more sense to me than our current model (which feels
more like a plain callback than a continuation to me). Some things that
occurred to me when reading this:
- This seems like it'll be much simpler to check for invalid concurrent access
to the same location (inout vio
We currently abstract over mutable property accesses using what I’ll call a
continuation-based model–the materializeForSet accessor is called before an
inout access, and returns a continuation callback that must be called when the
inout access is completed. I think a nested-function-based model,
10 matches
Mail list logo
