lint rule omit_obvious_property_types should be suppressed on public apis when type_annotate_public_apis is enabled.

[bsutton]

dart 3.7.

The follow code triggers a warning when the lint omit_obvious_property_types is enabled.

String packageVersion = '0.1.1';

The problem is that if you also have type_annotate_public_apis enabled then removing the type will trigger the type_annotate_public_apis warning.

If type_annotate_public_apis is enabled and the variable is part of the public api then omit_obvious_property_types should be suppressed for that variable.

[bwilkerson]

@eernstg

[eernstg]

There could be different ways to handle this. It seems reasonable to me to enable a lint like type_annotate_public_apis, and then ensure that there are type annotations on all public declarations.

However, it also seems reasonable to me if a developer or an organization chooses to enable omit_obvious_property_types and/or specify_nonobvious_property_types in order to have type annotations on some non-local variables, and not on others, based on the characterization of the initializing expression as having an obvious type or a nonobvious type. Insisting on having return types and parameter types on all functions, and yet allowing const version = '0.1.1'; and const myNumber = 3.14; doesn't seem unreasonable to me.

Yet another reasonable approach would be to have type annotations on public declarations, no exceptions, and then having type annotations on private non-local variables if and only if the type is nonobvious.

An interesting corner case is a public member of a private class/mixin/etc, including the case where said class is accessible to other libraries because of a typedef — is that member public?

We could easily come up with additional reasonable policies, there's no obvious end in sight.

Consequently, we might want type_annotate_public_apis to stop reporting non-local variables if omit_obvious_property_types is enabled, or we might want omit_obvious_property_types to stop reporting public variables when type_annotate_public_apis is enabled, and there might be additional policies as time goes by, involving these lints and/or others.

If type_annotate_public_apis is enabled and the variable is part of the public api then omit_obvious_property_types should be suppressed for that variable.

That is one possible way to enable those two lints to coexist, but not the only reasonable one.

I suppose the ability of one lint to change the behavior based on the enabledness of another lint is a new kind of behavior. WDYT, @bwilkerson, would that be feasible? Does it generalize properly to all the situations where lints are being checked?

It does certainly happen now and then that there is a request for lints to be configurable. One difficulty with this is that there is no end to the amount of smarts we could add to lints (or that we could specify for specific combinations of lints).

The simplest way to get the requested behavior would probably be to create a completely separate lint omit_obvious_private_property_types, which would never flag a public variable. Similarly, a variant of type_annotate_public_apis could be created which would never flag a variable.

[bwilkerson]

I suppose the ability of one lint to change the behavior based on the enabledness of another lint is a new kind of behavior.

I can't think of any existing lints whose behavior is changed by the enablement of another lint.

There's already a way for a lint to discover whether another lint is enabled, so this wouldn't be difficult to implement, but the hard part here would include

• Defining reasonable semantics. Take the case in question as a perfect example: there isn't a single reasonable answer for what it should mean if both lints are enabled.
• Explaining the semantics to users. I'm very concerned that we not build a system whose behavior is hard for the user to predict. I think it would be incredibly difficult for users if the description of a lint L1 ended up looking something like "by itself, it behaves this way, but if L2 is enabled, then it behaves that way, and if L3 is enabled it behaves some other way, unless both L2 and L3 are enabled in which case it behaves in a completely different way".
• Maintaining consistency. Every semantic would potentially need to be implemented in both lints and those implementations would need to be kept in sync. There's no guarantee about the order in which the lints are run, so the implementation couldn't take advantage of that. (The case in question is likely an exception, but I could see cases that aren't.)

There are probably other problems that I'm not thinking of at the moment, but those are enough to make me think that we don't want to go down this road.

It does certainly happen now and then that there is a request for lints to be configurable.

Yep. And we've consistently said "no" to this kind of request. Even though there are cases where some level of configurability would admittedly be useful, allowing configurability has a tendency to exponentially increase both the complexity of the tooling from a user's perspective and the maintenance cost for the tool maintainers. I believe that in the long run it ends up being more expensive than it's worth.

In my mind, allowing interactions between lint rules has the same cost / benefit analysis. It just wouldn't be worth it in the long run.

... create a completely separate lint ...

That is a simpler way, but that also places an extra burden on users (having to understand the differences between the variants and choose the right combination) as well as a mantenance cost for us.

The simplest is probably to suggest that users either (a) don't enable both rules, or (b) use an ignore comment in cases where the rules disagree.

[eernstg]

First, some lints are incompatible with other lints, and this is not a situation which can be avoided entirely.

In order to resolve the conflict, one approach would be to say that const myNumber = 42; is acceptable (and we can omit the type annotation int because the type of 42 is obvious), so type_annotate_public_apis should not report those declarations when omit_obvious_property_types is enabled.

Yet another resolution could be to say that even those declarations must have a type annotation (as in const int myNumber = 42;), and omit_obvious_property_types should stop reporting this kind of declaration when type_annotate_public_apis is enabled.

However, these two approaches imply that one lint should behave in a way which is determined by the use/non-use of another lint, and this is not something which is supported with the current approach to linting. (Also, it could make a lot of lints much more complex to understand.)

Finally, it would be possible to create multiple lints targeting subsets of the cases that the existing lints are targeting (so we could have omit_obvious_private_property_types which wouldn't conflict with type_annotate_public_apis, or type_annotate_public_nonproperty_apis which wouldn't conflict with omit_obvious_property_types, nor with specify_nonobvious_property_types). In this case the danger is that the set of lints grows too much (which means that it will be difficult to find the resources to maintain them, and perhaps even to select which ones to enable).

So there's no obvious resolution to this conflict at this time.

[frankvollebregt]

Perhaps it would be useful, for the time being, to mark these rules as mutually incompatible? Even though they are technically only incompatible in a few specific scenarios.

I noticed there's already a header for incompatible rules on the omit_obivious_property_types documentation page. Though I suppose it's difficult to explain the incompatibility within a reasonable amount of words.

[eernstg]

https://dart-review.googlesource.com/c/sdk/+/429662 marks the rules as incompatible.

[eernstg]

https://dart-review.googlesource.com/c/sdk/+/429662 landed, thanks @bwilkerson!

I couldn't see a way to adjust the documentation at https://dart.dev/tools/linter-rules/omit_obvious_property_types#incompatible-rules, that might happen automatically based on the declaration of incompatibleRules in the given lint rule classes, but if it is done manually then I'd need a hint about where/how to do it.

[bwilkerson]

I believe it's done automatically by a script that @parlough runs manually. (So a little of both.) Our part of the job is letting him know that things have changed so that he knows to run the script.

[parlough]

Hopefully it'll be automated soon, but I haven't had time to finish that track of work recently.

The site is now updated marking them as incompatible. Thanks! :)