Flow version: v0.97.0
When an object is destructured in the parameters of a function, I would prefer if flow Flow didn't produce errors that result from the possibility of re-assigning properties on the object. Having to mark Maybe properties as covariant can be somewhat tedious, and solving the error can be quite counter-intuitive for those unfamiliar with it since the function can't easily produce the error being guarded against.
I recognize that a reference to the object is technically reachable through the arguments object, but accessing arguments is now generally agreed as bad practice in most applications. Accomodating such use cases could involve annotation escape hatches, more strict application of type-checking when the arguments token is present in a function, or a flow config setting.
While I see how this can be inconvenient in your case :(, this is not a bug, but an explicit design decision in Flow.
myFunc (which takes the argument without the read-only / covariance annotation) could delete the key thing from the object, which is exactly what Flow's sound type system defends against.
Can you explain how it could delete the key without accessing arguments? Because the parameter has been destructured, it seems to me that there is no token within the function that can refer to the object in order to mutate it.
Most helpful comment
Can you explain how it could delete the key without accessing
arguments? Because the parameter has been destructured, it seems to me that there is no token within the function that can refer to the object in order to mutate it.