Add an "Effects" or "Rules" table for class modifiers

[skylon07]

Page

https://dart.dev/language/modifier-reference

Notes

What information is missing?

On this page, there is a very handy reference table that explains the combined effects of all the valid combinations of the various class modifiers Dart offers. I was looking at this table and thought to myself, "It'd be nice if there was a table that would explain what happens if I added modifier X". This individual effects table would look like something along the lines of

Modifier	Construct?	Extend?	Implement?	Mix in?	Exhaustive?
base	(No effect)	(No effect)	No	(No effect)	(No effect)
interface	(No effect)	No	(No effect)	No	(No effect)
final	(No effect)	No	No	No	(No effect)
sealed	No	No	No	No	Yes
abstract	No	(No effect)	(No effect)	(No effect)	(No effect)
mixin	(No effect)	(No effect)	(No effect)	Yes	(No effect)

(Disclaimer: I'm still a Dart newb so the above could come across as misleading or incorrect)

How does it provide value?

While you can gather this information from the existing table, it requires you to visually compare the class row with whatever <modifier> class you're wanting to understand. This is not only a minor annoyance to learning these modifiers; it is actually quite difficult when you look at rows further down like mixin class!

Another good reason is this table shows the contradictions some modifier combinations have, like final and mixin. What I mean here is in this new table, you could clearly see final and mixin are contradictory because mixin guarantees you can mix-in a class, whereas final guarantees you can't. There's no way to gather this information from the original table.

I also think adding it would provide a nice, natural segway to the "Invalid combinations" section to answer the question "Why are some modifier combinations not allowed if they have a well defined set of rules?"

How would you like us to fix this problem?

Add the table I described above in a new section, perhaps titled "Modifier effects" or "Modifier rules". It makes sense to me to insert this section between "Valid combinations" and "Invalid combinations", however this just my opinion and not important to the actual suggestion I'm making.

I'm also unsure if class should be included or not as an actual row. I'm leaning more against including it, since the "Yes"/"No" cells are meant to be "guarantees", which class doesn't provide any by itself. I think it could be helpful to reiterate somehow that each modifier is some kind of "application" or "modification" on top of the default behavior class provides, but this could also just be redundant information since this table is meant to be more of a reference (and, I mean, it's literally in the name "modifier").

Edit: Thinking about this more, I still think the above is true, but a distinction should be made that mixin is not exclusively a modifier to class the same way the other modifiers are (that is, mixin Asdf {} is valid, but sealed Asdf {} or interface Asdf {} is not). In other words, mixin can guarantee a type can't be constructed, but only if it's not paired with class. Otherwise, it has no effect on construction, like the table above suggests.

[antfitch]

@parlough what are your thoughts here? I'm wondering about complexity.