Delegation in yielding accessors

Using Swift
1

I've been playing around with noncopyable types, and one pattern I find myself repeating recently is to have a somewhat useless _read accessor (which will become a yielding borrow once yielding accessors land). The reason _read is useless in my case is that the property is mostly intended to be written to from the public API, and consumed only internally (in my case, this is often a stream which is being parsed and the public api is something like parser.stream.push(additionalData). I need this to be a computed property because sometimes the underlying state is represented as an enum of case stateA(stream), stateB(stream)).

As such, I'd love to be able to basically do:

var stream: Stream {
  mutating _read {
    // call `_modify` somehow?
  }
  _modify {
    ...
  }
}

But I'm not sure exactly how to write this. Is this currently possible? Do we need the restriction that a computed property implementing _modify must also implement _read? Will any of this change once the new yielding accessors land?

2

Since Swift doesn't have a notion of write-only properties, there does need to be some accessor that can serve read requests for the property. That could in principle be a _modify coroutine, and that would probably be just fine for your situation. However, since a modify coroutine is mutating on the base, using _modify to do a read operation would make it so that reads were also mutating on the base, which is fine for your case, but could be surprising in other situations. It might be interesting to allow a property to specify only a _modify coroutine, but I wonder how often the read behavior would catch developers off guard.

3

Swift already has mutating get (and mutating _read), which I admit are surprising sometimes but do have valid use cases. I think the issue here is that there doesn’t seem to be a way to call the _modify accessor from a mutating _read accessor. I can write the mutating _read manually, but that is a bunch of code duplication and bug surface.