@Devin_Coughlin @John_McCall, a user reports an issue with spotty exclusivity enforcement in their code inside a didSet:
Ideally, to me it seems like the exclusive access to a property with a didSet should end right before invoking the didSet observer, in order to keeps things like what he's trying to do working. Is that possible in the implementation model?
Remember that a didSet can modify a property too without going back through the accessor. That implies you still have exclusive access.
For a struct property with static enforcement, perhaps, but for a class property or nonmutating set properties in general I think it's implementable to start an independent dynamic access if you write to the property from didSet. This also seems like one of the major use cases for observers, triggering updates in response to a change in a class's state, which is naturally going to trigger potentially arbitrary code trying to read the new state.
Regarding nonmutating setters:
[SR-7268]: [SILGen/exclusivity] call to nonmutating setter is not a mutation.
That only applies to the base value, unless I'm misunderstanding. The implementation of the property dynamically asserts exclusive access to the storage, doesn't it? I'm asking whether that dynamic assertion could be shortened in the case of didSet observers, letting writes from inside the didSet re-assert exclusivity if needed, so that the didSet code can freely pass references to self around to code that will read the new value.
I agree that the call to didSet should probably be outside of the formal access to the underlying storage.