💡 It may be sufficient to move this to a separate diagnostic analyzer/code fix, where it would be applicable both as a follow-up for this refactoring and as a helper for code that enabled nullable reference types through other strategies.

what are the odds of this happening in practice? i'd guess either:

1. very low
2. only for very common/obvious syntactic forms (like enums)

Given this, i would instead only look for really obvious cases to remove. Beyond that, just leave in.

➡️ For now, opting to not implement this. We can create a separate diagnostic analyzer in the future to point out redundant directives, and at that point leverage it in this refactoring to improve the results.

💡 It may be sufficient to move this to a separate diagnostic analyzer/code fix, where it would be applicable both as a follow-up for this refactoring and as a helper for code that enabled nullable reference types through other strategies.

i would only look for the most basic case. Specifically, if the file now starts with #nullable enable and nothing else, then remove that. If there's any sort of multi-directive stuff going on, then leave it alone.

➡️ This simplification is now implemented. Further identification of redundant #nullable directives can be implemented as a separate diagnostic analyzer.

something feels fishy here, though i can't quite put my finger on it. i think it's that disable doesn't change, while the other two rotate. i trust that this logic is correct? my feeble brain keeps getting confused by it :)

💭 It's strange, but it seems to be correct. With Nullable Reference Types disabled, #nullable disable and #nullable restore have the same meaning.

this seems fine. though perhaps it should be a loop? though i guess the change of having multiple empty regions in a row is so low as to be pointless :)

💭 Yeah, the main goal here was to not mess up a known file header pattern.