provide a more aesthetically pleasing @override

[lukepighetti]

@override is currently optional. it makes classes longer and more verbose than they need to be. here are two ideas for improving the aesthetics and i'm happy to hear other ideas.

1. deprecate @override
   1a. schedule it for removal from the language

pros: it's optional and not needed. deprecating it should be straightforward. removal could be scheduled out indefinitely or 5+ years

cons: it will be harder to tell which methods override superclass methods. maybe there are lsp features like virtual text that could help instead

(this one is my preference because perhaps due to my mechanical engineering background deleting things that are optional is basically a blood sport for people like me.)

2. create an override keyword (see swift)
   2a. make this keyword required on a method if the superclass has a method with the same name
   2b. require removal of the keyword if it exists on a method who has no superclass with a matching method
   2c. deprecate @override and schedule for removal

pros: one line. explicitly marks overriding methods. make required instead of an optional warning as it currently is.

cons: makes class declaration lines longer. but that's less of an issue with configurable dart format line lengths

i'm personally less inclined to this option because it doesn't provide much value over what we currently have

[dart-github-bot]

Summary: User dislikes the look of @override annotation. They propose deprecation or a new override keyword for improved code aesthetics.

[RohitSaily]

I’m not a huge fan of the aesthetics of the @override annotation either. However, I do think it makes sense to keep it, as it improves clarity—especially when dealing with large codebases. Additionally, it’s possible to silence the requirement for it project-wide by making a single change in the analysis_options.yaml file, so those who prefer not to use it have that option.

That said, I agree that @override feels a bit long, especially since my personal coding style keeps annotations on the same line as the declaration. It would be great to have an abbreviated version, or perhaps a general feature that allows aliasing annotations so this is not a recurring issue with other annotations.

[lukepighetti]

did a little more digging and it looks like languages either have a required override keyword (kotlin, scala, swift, c#, c++) or an optional @override (dart, java) or a missing implicit (rust, python). i could not find any examples of abbreviations but happy to hear ideas.

[RohitSaily]

I am not aware of any established conventions for an abbreviated version. Although, I can come up with some reasonable names to play with:

@sup
@mod
@over
@super
@change
@supers
@replace

I personally prefer any one of the first 3.

sup can be interpreted as super or supersede.

mod for modify i.e. modify an existing definition.

over is just an abbreviated version of override

[lrhn]

Making it a language feature is a language request, and there is already a request for that: dart-lang/language#1610
So, great idea! (I have to say that since I filed that request).