[Class Modifiers] Consider allowing type aliases to remove capabilities.

[leafpetersen]

[This is not a proposal for the current release, but leaving this as a quick note for something we could consider in future releases]

Some of the design of the class modifiers feature is driven by use cases in which a user may wish to have more capabilities within a library than they wish to expose externally. We support this to a certain extent since users are free to ignore restrictions within their own libraries, but as @lrhn notes here there are still places where finer granularity might be useful. One approach to handling this might be to allow class modifiers to be placed on appropriate type aliases to expose an existing class with fewer capabilities. That is, given:

class A {}

we would allow

base typedef ABase = A;

Here, A would support both implementation and extension, but ABase would be restricted to extension. This would support use cases such as those described in #2908:

class _SetBase<T> {...}
class SuperSet<T> extends _SetBase<T> {...}
base typedef SetBase<T> = _SetBase<T>;

Here, we allow SuperSet<T> to be extended or implemented arbitarily (since _SetBase is not restricted), but the exposed name SetBase will only support extension.

cc @dart-lang/language-team

[lrhn]

I think we can probably give this a consistent semantics.

It would mean that the access capabilities are not an inherent part of the type, but more like metadata carried along with the type, which is why a type alias can modify them on the way.
An interface class A declaration would not be a class which cannot be extended. It's a class, and the reference to it that you get through writing A has the restriction that it cannot be extended. A typedef final B = A; would make B denote the class A with the restriction that it cannot be extended or implemented. Like the type reference has been "promoted" to final when referenced through B.

If you add base or final to a type alias, it will force anyone going through that alias to prevent implementation, but it won't affect any class going directly to the original declaration. It doesn't actually guarantee anything, it just forces compliance in subtypes declared through the alias.
(I'm sure I can use that for something clever! 😈)

The obvious next questions is whether a type alias in the same library can remove restrictions?
Maybe. That's more complicated, because if the actual class is base, all subtypes must also be base (as currently defined), and then the typedef itself must be marked base (or more). But there is no inherent problem with a typedef B = A; which allows extending A, removing an interface restriction. You could always write @reopen class B extends A {} anyway, and reopen it that way.
So, you can maybe re-add the ability to extend, but not to implement, in a type alias, go from interface to nothing, or from final to base.

That prompts the question of whether you have to write a modifier or not.
It would be convenient if writing nothing gives you the original modifiers of the aliased type, but that would mean you can't go from interface to nothing, if writing nothing inherits the interface. We'd need a keyword for "nothing" then (say open). Nothing wrong with that, we could add it, and it's just the default on class declarations if you write nothing, but not on type alias declarations.

You probably can't do anything special with an alias for a sealed declaration. It would automatically be just as sealed, and you can't remove that.

[eernstg]

I think I like it! ;-)

We already have the ability to use type aliases to provide access to a given type declaration with some added constraints. E.g., #524 (comment) uses this to enforce a particular relation between actual type arguments, and we could also use it to enforce some stricter bounds on type parameters.

About the ability to specify stricter class modifiers (OK, I'd prefer that we only allow stricter ones), we'd need to think about a couple of things:

• How should we understand a type alias with no class modifiers? There is a certain ambiguity here.
  • It could be an error to have them (typedef final T = dynamic;, typedef base F = void Function(int);); in this case, 'no class modifiers' is a simple matter of not being an error.
  • It could be a choice (class A {}, typedef B = A; because we want B to have no class modifiers).
  • It could be a legacy property (it's really interface class A {}, and typedef B = A; has been around long before A became interface), in which case we might want to say that "no modifiers" means "no change".
• Does a type alias with a class modifier always have to be declared in the same library as the target type?
  • With class S {} in L and typedef sealed SAlias = S; in L2, we could of course insist that every immediate subtype of SAlias is declared in L2, but it wouldn't provide any guarantees. Is that what we want? Should the class modifiers of a type alias A always be interpreted as if they had been specified on the target type?
  • A type alias probably should not introduce an edge in the superinterface graph, so whenever we have a rule that talks about direct superinterfaces we must skip any number of type aliases in order to find them. Do we carry the class modifiers of the skipped type aliases along and consider them as specified on the non-type-alias that we find after skipping?