Add a hint @nonVirtual for class members

[matanlurey]

... or, to help developers when defining the intended use of a class, and to help users use a class properly (i.e. as intended by the class). I'd find this extremely useful when working on fairly complex classes with lots and lots of member fields and methods.

Similar to the spirit of @sealed (#27372):

import 'package:meta/meta.dart';

class X {
  @nonVirtual
  void alwaysPrintFoo() {
    print('Foo');
  }
}

class Y extends B {
  // HINT: X.alwaysPrintFoo is marked @nonVirtual and should not be overridden.
  void alwaysPrintFoo() {
    print('Bar');
  }
}

General concept:

• Issue a hint when a member annotated with @nonVirtual is overriden.

Because of how this annotation would need to work, I imagine it would also need to:

• Issue a hint when a class with one or more @nonVirtual members is implemented (implements - not extends/with), as by definition a class with @nonVirtual member requires the original implementation:

  import 'package:meta/meta.dart';
  
  class X {
    @nonVirtual
    void alwaysPrintFoo() {
      print('Foo');
    }
  }
  
  // HINT: Cannot implement a class with one or more `@nonVirtual` members.
  abstract class Y implements X {}

• Issue a hint when an abstract member is annotated with @nonVirtual. Also impossible:

  import 'package:meta/meta.dart';
  
  abstract class X {
    // HINT: Cannot define a `@nonVirtual` abstract member.
    @nonVirtual
    void alwaysPrintFoo();
  }

/cc @davidmorgan @srawlins for thoughts.

[rkj]

I do like it, would be definitely helpful in many APIs. Why not call it @final to align with Java?

[matanlurey]

I believe that is a reserved word/keyword in Dart. It could be @finalMember, but meh.

(I don't care about the name, to be clear, it can be whatever folks agree on)

[matanlurey]

An alternative is just to support @sealed on member methods/fields, of course!

/cc @srawlins

[filiph]

I keep getting into situations where I'd like to have this functionality.

For reference, an old school issue from @danrubel asking for language-level support of this is here: #3928. I'll update that issue to link here. I do think it's better (and more practical) to implement this via pkg:meta rather than having it in the language.

[rayfarias56]

Also just ran into a situation where this would be useful. Any updates on the priority? I'm willing to contribute the change, just not sure where to begin.

[hacker1024]

It's now October 2019, and this issue's been open for over a year. can someone on the Dart team let us know what they think about this?

[pq]

I'm all for revisiting this. Specifically, it could potentially be used to disallow overriding Widget equality in Flutter (which otherwise we'll have to analyze specifically for). See #58035 and it's inspiration: flutter/flutter#41220 (comment).

[pq]

OK, running w/ @nonVirtual:

https://dart-review.googlesource.com/c/sdk/+/122701

[pq]

Implemented in server and landed in package:meta:

Looking forward to seeing how folks take advantage!