Allow in-place mutation of NIOLoopBoundBox.value

[dnadoba]

Motivation:

NIOLoopBound and NIOLoopBoundBox should be lightweight wrappers and support in-place mutation of CoW (Copy on Write) types.

Modifications:

• replace set accessor with _modify accessor
• add test that verifies in-place mutation of CoW types

Result:

Less copying

[weissi]

@Lukasa What's the current position on _modify, is that now allowed? Alternative is obvs to make a withMutating { inout ... }?

[FranzBusch]

We have used _modify and _read in multiple places now for performance. I think at this point it sadly is allowed to be used.

[weissi]

fine by me

[dnadoba]

I have completely switched to use _modify by default if the property type can be a CoW type.
Combining this with consume self if the property isn't simply a stored property and I can implement efficient computed properties without worrying about triggering CoW. The CoWValue test helper then makes sure this actually checks out and stays like this.

[weissi]

Hmm, I don't think that's a good development. There are still open questions about _modify which is why it's underscored. And _modify is probably less benign than other underscored stuff like @inline(__always) or @_cdecl. The precise semantics haven't been settled and things may change.

Anybody aware of a post-2022 effort of getting these accessors specified?

[weissi]

The concern is that it's an underscored (i.e. not ready for prime time) feature whose semantics aren't fully specified.

The standard library is developed and shipped together with the compiler itself which makes it different. Example: Before Swift had a defined memory model, the standard library pretended there to be a defined memory.

Regarding swift-collections: That's up to the Swift collection authors.

Concerns regarding _modify: It's very easy to go wrong. For example if you have this code

_modify {
   print("A")
   yield &self._something
   print("B")
}

then you will not always see B after you saw an A. It depends if there was a throw in the mutation. This can leave your type in an inconsistent (possibly memory-unsafe) state and is arguably hard to see (there's no try or place to catch). Sure, if the yield is the last line in a _modify then it's probably fine.

But fundamentally, we can just offer a func withMutableValue { inout Value ... } which can achieve the same as _modify (worse syntax ofc).

---

This is just a decision for the NIO team. They maintain the code base, so they need to be comfortable with the amount of undefined, underscored stuff that's in the code base at present. New compiler versions could adjust things for underscored features.

[dnadoba]

That is fair and matches my understanding of the risk. It's a trade off, similar to the use of unsafe or unchecked swift features. The pitch explains this as well. Are there any other known issues today?

possibly memory-unsafe

@weissi is that possible without additional use of unsafe swift?

---

Agree, thats up to the NIO team.

[weissi]

possibly memory-unsafe
@weissi is that possible without additional use of unsafe swift?

I would assume so because compiler-emitted code could be skipped too (unless it protects against that). The key point is: Without an _modify implementations checked against the current compiler invocations we don't really know.

[FranzBusch]

I am personally okay with using _modify since it is used by the compiler and standard library developers outside the stdlib e.g. swift-collections. It makes the code that developers write fast without them having to discover a modify method. Additionally, we are using more underscored attributes such as @_exported or @_alwaysEmitIntoClient.

[Lukasa]

If we're using @_alwaysEmitIntoClient we should definitely rethink that too.

@_exported is underscored, but its behaviour is well understood and safe. _modify is definitely not that.

As you know, the compiler and standard library developers explicitly do not make the same compatibility promises we do. That allows them to freely use these annotations, as they can always resolve issues by dropping all prior Swift versions. We can't do that, so if _modify introduces issues, we'll be forced to fork or revert the change.