Non-virtual and re-declared virtual members. about language

[mateusfccp]

I'm a little lost in this example.

Example:

class C {
  new 
  int foo() => 42;
}
class B extends C {
  override
  int foo()=> 37;
}
class C extends B {
  final override
  int foo() => 87;
}
class D extends C {
  new 
  String foo() => "Not a C.foo"; 
}
class E extends B {
  new 
  String foo() => "Not a B.foo";
}
cl;ass Bad extends C {
  override
  int foo() => 0; // Cannot override final member, no non-final member to override.
}

Maybe you did mean that the first class is called A? I can't see why we can define C twice, much less how both B depends on C and the second C depends on B.

[eernstg]

I like the ability to indicate that a given declaration is an override (and the permission to omit that modifier, plus a lint to recommend it anyway).

I think the ability to use final on a method would be interesting. It could be used to insist on using a specific implementation for that method for domain specific reasons (some notion of correctness that is outside the realm of type checking). It would then presumably go together with base on the class. The same consideration comes up if a method is final because we want to get the guarantee that method invocations can be resolved statically and the method can be inlined, etc: That also only works on a base class. (And that's a base class that hasn't been reopened, of course.)

However, the use of final on an instance variable does collide with this new semantics of final.

On the other hand, I'd prefer to avoid the introduction of new on a member: A semantically different member should have a different name. If many different members have the same name and we'll get a completely different behavior if the receiver type is a little bit different then we could have some very subtle bugs based on tiny differences in control flow that changes promotion and type inference.

[lrhn]

However, the use of final on an instance variable does collide with this new semantics of final.

It does. And final final int x = 42; is already suggested for stable variables (and shot down for being too silly by half).
And it's not unreasonable to have a non-overridable but modifiable instance variable, so just counting wouldn't work.

Need more keywords. :)

[munificent]

I like final and override, but I don't feel like new is a good fit for Dart, at least Dart as it is today. One of the fairly deeply-ingrained parts of the language is that a class has a single flat namespace for members with no name collisions. Not even overloads.

A new modifier would introduce some notion of shadowing for members. The use cases for that, as far as I know, are quite rare. I think you run into it sometimes in C# because you really need to evolve an API but must also do so in a backwards compatible way. A shadowed non-virtual method can sometimes get you out of a pinch.

But in Dart, we have long had a pretty strong package ecosystem that supports versioning, so it's relatively easier for users to just actually change their APIs in breaking ways. Given that, I don't think new would buy us much.