Allow Ignore Refinement Invalidation checking for specified maybe variable/prop/member
- Dominant language
- Rust
- Stars
- 22.3k
- Forks
- 1.9k
- PR merge metrics
- No merged PRs in 30d
Description
_It would be great if_, in the [linked example](https://flow.org/try/#0PTAEAEDMBsHsHcBQiDG0CGBnToCCBlWFAawFMAXUAb0VFAH1Nz1zSAuUABlAB9QBGANy1QKWADsmAJwCuKcrCkAKAJTURdcgAsAlpgB0jZq1ABeLsLoBfZHSYtSqjtz79qoKRRlTxF0DboxcXFSeVV3bT1DexNzIX8RABM9IJCwtSpQSIMjBzM-ANAJJVIAN1Jxcg5pHXEAcwAaUQAjDgAxGXF5HQkMwswKxKUAW0w66vIpWrq+xBtUDGw8QhIKAFl0cXQ60il1OkYOAH4CIjJyYREg6TkFZQyNLN0DVNDyVRF5uj0AYQk01hDFQcZqwWDQUibfZ0UAgUAAB1grEqOnQ0GgAE9RLBhvCIQAPUBwOo6FCgJSYWCgAAiACUAJoqR6ecjeXwAQnZ2WioAAZLynlFGPoYqQzKY4pYEld-m9wjQYaAdJByVznvpfrL5KQgQ9FZp1Yx8iF4MszhRVFLFdzhcUAOTDUjYbakO1NcKmAB81CsKitMJtBntuykijd5LUXp9fpEcNAAD1RGjoEUVY7tLBEqAAAYSbP6UBrChaTNJ4JI0DNMUoZM6oq+RHYHTNTGgcQydGgUpomSkWNgBNJzuwNPF0u58T5wtjrM18uUKtDiFZiQI2BNltYzqJUiQWp17vQXuPQpfbHBN4AdUUxHQoe38seEMoOHMgf9cMRyPIqPRWLEuIEkSsAkmSSjNJ46DEDgdKMo8yqqjgPB8AYoqgOyEoCHq+qvm2pCmqcqzvDG+qgEG4hKA6TqYC64Yet6VC+v6dj6MGUihlIdGRgxTGPAaQq4Zg-qnrYoDJJgrzpNC3wqko3Kahe2q6tJAaGgY4mScRUpxomNbDqOGZZtmGlauQU5FoZZbiBWi56cu9Zrhurbtp2h7HnQOlLqmoDpiWRkmYpZkFhZflWTZ1a1iuDbrpgzattuu77lmbl9qRgb5Ale4hIkwmfKJAUAteUhkHesAPthgQSEwZH5O+jyfkiFQ-sm-44nipCEsSpLkhBkLQTSDJMoqCEUnyAqocYYoSnEFUwupKSmZafGCjkuGZUluXWHMiBAA), it was possible to tell Flow to trust that _maybe_ property `_s: ?ASocket;` will be managed by the user and therefore immune to `...possibly undefined/null value` errors due to _potential_ side-effects as explained in [Refinement Invalidations](https://flow.org/en/docs/lang/refinements/#toc-refinement-invalidations). It would be easy to have unit tests that cover this.
I completely get why this is done and the effect of side-effects and it is a great catch for potential errors. However, it would be nice to be able to ignore specific cases where the logic related to said property (or variable, etc) gets complex and where it makes more sense to practice DRY to prevent the spread of this logic throughout the code base. The latter IMHO would cause more potential for errors than possible side-effects.
So something like (`// $FlowIgnoreSideEffects` or `// $FlowIgnoreRefinementInvalidations`):
```js
// @flow
class ASocketManager {
_s: ?ASocket; // $FlowIgnoreSideEffects
...
}
```
Contributor guide
Assessment
This issue has not been assessed yet.