> On Nov 1, 2016, at 11:00 AM, Jordan Rose <jordan_r...@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 _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
