Linter: Should type_annotate_public_apis lint final field?

[a14n]

type_annotate_public_apis lints the following code:

class A {
  final a = ''; // LINT
}

As a is final it's always a String. Should the lint be discarded in this case of final vars?

[bwilkerson]

Good question. Type inference might change this and several other style-oriented lints.

[kevmoo]

Let me enthusiastically agree with this!

If the type can be inferred (and it's a public type) then it shouldn't cause a lint!

[kevmoo]

CC @pq

[pq]

It's interesting to note that the referenced style guideline does allow for some wiggle when it comes to "obvious" types. I'm definitely open to refinements.

What does dartdoc do in these cases? (And does that matter?)

/cc @jcollins-g

[kevmoo]

dartdoc "does the right thing" 😄

https://pub.dev/documentation/source_gen/latest/source_gen/defaultFileHeader-constant.html

[pq]

/fyi @bwilkerson

[mr-mmmmore]

Will something be done about this? At the moment we still have to write

Class A {
    final MyClass myProperty = MyClass();
}

to comply with the type_annotate_public_apis rule.

But effective dart says PREFER type annotating public fields and top-level variables if the type isn’t obvious:

In some cases, though, the type is so obvious that writing it is pointless:

const screenWidth = 640; // Inferred as int.

“Obvious” isn’t precisely defined, but these are all good candidates:

• Literals.
• Constructor invocations.
• References to other constants that are explicitly typed.
• Simple expressions on numbers and strings.
• Factory methods like int.parse(), Future.wait(), etc. that readers are expected to be familiar with.

[pq]

Thanks for the nudge @mr-mmmmore. I think we've reached consensus that we want to support this and I'll put it on my short-list to take a look at updating the rule.

[mr-mmmmore]

Cool! Thank you @pq