implement `@reopen`

[pq]

From the base-interface-final spec:

@reopen lint
...

A metadata annotation @reopen is added to package meta and a lint "require_reopen" is added to the linter. When the lint is enabled, a lint warning is reported if a class or mixin is not annotated @reopen and it:

• extends or mixes in a type marked interface or final and is not itself marked interface or final.
• extends, implements, or mixes in a type marked base or final and is not itself marked base, final, or sealed.

See also: #58976

[bwilkerson]

I don't understand the value of this annotation. The proposed lint ensures that the annotation is provided, but other than silencing the lint the annotation appears to have no impact on analysis. If the only value of the annotation is to silence a lint, and the only value of the lint is to require the annotation, then neither has any value. What am I missing?

@munificent

[pq]

The way I understand it, require_reopen will likely be a core or recommended lint which means that in the common case folks will get a diagnostic if they try and un-seal a sealed class without explicitly marking it with @reopen. If I understand the proposed value, it's to ensure that sealed classes aren't opened accidentally.

Or maybe I'm missing what you're missing? 😉

[lrhn]

What @pq says. The lint is to avoid reopening a closed class accidentally in a subclass. The @reopen annotation silences the lint and states that the reopening is deliberate, the same way the unawaited future silences the unawaited_futures lint when not awaiting is intentional.

It's a lint with false negatives, but still with (expected) enough value that it's worth dealing with those negatives.

[bwilkerson]

Ok, thanks to the analogy I think I understand. In the same way that not-awaiting a future is a foot gun, so is not sealing a subclass of a sealed class (etc. for the other conditions).

Then the purpose of the lint isn't to require a @reopen annotation, it's to prevent unintentionally reopening a class or mixin. I'd like to propose, then that we name the lint something like unintentional_reopening so that the purpose of the lint is more clear.

[lrhn]

SGTM. @munificent

[munificent]

Ok, thanks to the analogy I think I understand. In the same way that not-awaiting a future is a foot gun, so is not sealing a subclass of a sealed class (etc. for the other conditions).

Then the purpose of the lint isn't to require a @reopen annotation, it's to prevent unintentionally reopening a class or mixin.

Exactly right. Though, personally, I'm not yet convinced that this lint should be recommended or core. We'll see how much of a footgun it actually is in practice.

[pq]

Implemented in c8df557