Closed Thom1729 closed 3 years ago
This fixes an error case, but I still see potential for confusion when a "complex" object is constructed by the selector and modified in place, since the callback is called by reference, but that is a slightly different issue. To tackle that, we'd probably need a mutex and a second call of the selector to ensure we get two copies of the same state without relying on the data to be copyable, which is definitely not ideal.
Besides, I don't think it is currently documented that the selector's result must be equatable.
That's a good point. I think it could be handled separately from this bug, though.
Before this change, the saved value of a setting wasn't updated until after the callback was completed, so if you changed that settings object inside the callback, it would incorrectly detect that the first setting had changed again.