There are sort of two ways to go about this:

• Actually add a language feature (probably case .first(inout test))

• Just add the modify accessor for a case and allow it to be used as an optimization when the value is soon to be dead.

I think it'd be valid to do the latter without breaking ABI as long as it's not in libraries with -enable-library-evolution just yet.

cc @bob-wilson, @atrick, @rjmccall

I don't know what a `modify` accessor has to do with this; `case` is always totally physical. Point 2 is just saying that we could recognize that `self.base` is dead on that path and can be destroyed immediately, making `test` hold a unique reference. I agree that that's a possible optimization here.

Oh, right, that would work too.

`self` is the address of a mutable object. `test` is a value loaded from that object. The basic challenge is to analyze all paths from the load of `self.base` to the point at which it is rewritten. If there are no other reads from `self.base`, then the load of Elements can be converted to a load_borrow.

The bad news is that's much easier said than done (it's hard to see how a series of algebraic SIL transforms will eventually lead to the optimize. It looks like one heroic analysis is needed to me). One sticking point is that the copy occurs when Elements is loaded, before switching over the cases. So removing the copy is not at all straightforward.

The good news is that this is the sort of thing will be much easier to do now that we have exclusivity. It will also probably be easier with SIL ownership-SSA. I feel compelled to point out that SIL opaque values will not help here.

It's something we should prioritize, but might not happen until after some fundamental SIL rearchitecting is done:

<rdar://problem/50463362> [SR-10605] Enum cases should provide a modify accessor for their contained objects to avoid CoWs

Great test case!

@Lukasa Adding a self.base = .second before modifying the payload should workaround the problem.

Thanks Erik, we’ve got a couple of workarounds in place for this already that rely on that.

Correction to my comment above: SIL ownership is available late enough now that we might be able to inject this optimization early enough in the pipeline without being blocked on other work.