Linter: Warn when a nullable final field is initialised.

[dark-chocolate]

class A {
  final int? b = 1; // Should provide a warning here. 
}

In the above code snippet, there is no meaning of having int? when the field is declared final and hence it should provide a warning in the editor to either make it non-final or simple remove ?.

Flutter doctor:

[✓] Flutter (Channel dev, 1.21.0-7.0.pre, on Mac OS X 10.15.1 19B88, locale en-GB)
    • Flutter version 1.21.0-7.0.pre at /Users/chocolate/flutter
    • Framework revision 5a6dfa35ca (13 days ago), 2020-08-03 10:33:07 -0700
    • Engine revision 083282e33b
    • Dart version 2.10.0 (build 2.10.0-4.0.dev 365525432a)

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/chocolate/Library/Android/sdk
    • Platform android-29, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 48.0.2
    • Dart plugin version 193.7361
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[lrhn]

Whether it's needed depends on the use-case.

If you are creating a class where the b getter is intended to be overridden in subclasses, and those subclasses might need to return null, then you need to make the type nullable. That is, always warning here could be a false warning, and you would have to add an ignore for it to avoid the warning.

Because it might be a valid, deliberate choice, we'll probably not make a warning here be part of the language specification.
The analyzer can still choose to add a hint, if it thinks the use is wrong.

[dark-chocolate]

@lrhn Since I don't come from English background, so in reality I meant to say Dart should provide a hint here but I used the word warning.

[lrhn]

Don't think that native English speakers would be any better at knowing the difference. 😄 (But I wouldn't know, I'm not a native English speaker either).

We in the Dart team are fairly particular about the distinction between errors (program won't compile), warnings (usually language specification mandated, high probability of it being an error), hints (analyzer provided, may just be a recommendation or suggesting that you check that it's OK), and lints (extra opt-in checks to help you follow a particular coding style, or avoid particular dangers).
It mattes to us because it determines who is owns the feature (language, analyzer or linter teams), and where it must be specified, but to most users, it's probably just "some kind of warning", and that's perfectly fine.

[srawlins]

Transferred to linter project; the diagnostic should be a _lint_ since there is plenty of room for false positives.