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

[Joe Groff]

> On Nov 1, 2016, at 11:00 AM, Jordan Rose <jordan_rose at apple.com> 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 check for invalid concurrent access to the same location (inout violations) in debug builds. (I don't think it's actually any more or less possible, but it is simpler.)
> 
> - This will look funny but work fine for multiple inout parameters: foo(&x, &y)
> 
> - OTOH, this does break up basic blocks in the caller context, making LLVM analysis less effective. Since the materializeForSet calls were already either inlined or opaque, though, we're probably fine there.

True. John mentioned that LLVM has grown some support for subfunction extraction in support of C++1z coroutines; we might be able to leverage that so that the IR still looks materializeForSet-ish even though we lower things differently.

> - Does this help us with the nested dictionary CoW problem? `foo["bar"]["baz"] += 1`

I think the dictionary problem can be addressed in either implementation model, if we open up the language to express generalized "mutators" instead of just special-cased addressors. With strict enforcement of `inout`, the dictionary implementation would have the worst-case freedom to move an indexed value into a temporary without copying it, and move it back at the end of the access, if we're unable to otherwise represent it entirely as an in-place operation.

-Joe