Allow `sealed base class`, because it is useful

[jakemac53]

In general I think our logic for what the valid combinations are was a bit flawed because we used the table for what is allowed in other libraries, but should have used a table based on what is allowed in any library (including the current one). There may be other valid use cases that are not allowed, other than this one, from within the same library.

Use case

You have a sealed class, and you want to ensure all possible implementations of that class are transitive extensions of it.

You can achieve this today by making all the subtypes in your library be themselves base classes, but it could be easy to miss one on accident, in particular when adding new ones. Allowing sealed base would allow you to enforce this property, since base is transitive even within the same library.

Concretely, this is coming up for the Code class in macros, I want every piece of Code to ultimately extend the base sealed class, but they must go through some more specific subtype to get there (DeclarationCode, ExpressionCode, etc).

It is OK for people to build their own subtypes of those, but only through extension. We want to be able to put in some form of validation in their constructors, and ensure that those constraints are met.

[rrousselGit]

Could we do so for sealed mixin class too?

[lrhn]

We have no modifiers for controlling what is allowed in the current library, because they don't work anyway.
Even if you could declare a sealed base class, you can still implement it inside the same library, the base doesn't affect you.
The only thing it does is to force you to put base on every subclass (at least until #3108).

Which is precisely what you want, to help you from forgetting to add a base to a subclass, but it's not a lot of benefit for allowing a new syntax combination.

Workaround:

abstract base class _RealSuperclass { ... }
sealed PublicSuperclass extends _RealSuperclass {}
// all subclasses must be `base`-or-more.

Or even

abstract base class _Based {}
sealed Superclass implements _Based { ... }

(But that is getting a little silly, might as well allow the sealed base if that's what we'll recommend doing instead.)

(I'm much more sympathetic to sealed mixin and sealed mixin class, which can be worked around too, but not in any pleasant way.)

[jakemac53]

It just seems very arbitrary to me to block this particular combination - I don't think it is a crazy situation or anything. It is in fact the very first sealed class I have ever tried to write and I ran into it.

Yes there are workarounds, but I don't really see why they are necessary, given we already have the modifiers.

It was my understanding that we chose to exclude the combinations of modifiers that we thought were useless, but in doing so we used the wrong table, and should add back the ones that are in fact useful, when the correct table is used (the one that includes capabilities within the current library).

[lrhn]

Can you elaborate what you mean with "capabilities within the current library"?
(Because you always have all the capabilities inside the same library, without doing anything.)

The reasons sealed base was excluded was not because we removed it from a table. It was never in a table because we treated base and sealed as mutually exclusive modifiers which would go into the same position in the declaration.
@eernstg had a proposal to make sealed orthogonal to base/interface/final (can't find that now), but we didn't do that.
So sealed base wasn't even in/on the table to begin with.

Should it have been? (Well, Erik thought so. He didn't manage to convince everybody else.)

We did focus mainly on the effect of the modifiers on other libraries because the modifiers doesn't restrict the current library anyway. If you can express all the effects you want on other libraries, you can write a library which satisfies that.
Sometimes it means adding base to all the subclasses of a sealed class. But there is nothing you can do by writing sealed base that you can't also achieve without it, by editing only the same library.

(Not saying I'm against allowing sealed base mixin class declarations. Just saying why we didn't consider them necessary originally. I'm usually in the "allow all the combinations" camp, although sealed base wasn't something I originally thought necessary.)

[eernstg]

I think we're in a perfectly good position to allow additional combinations of keywords (following the compositional semantics that we already have). As @lrhn mentioned, I argued already a while ago that the ability to mark a sealed class as base as well could be useful, cf. #2755 (comment), section 'Sealedness'.

We might want to wait a bit and see how the usage evolves, but if we decide at some point that the introduction of keyword sequences like sealed base class is a good idea then I don't see any technical difficulties or ambiguity issues with that.

.. we treated base and sealed as mutually exclusive modifiers which would go into the same position in the declaration

This might have been a visual preference, I don't see any technical reason to consider them mutually exclusive.

[lrhn]

It's quite possible that sealed base is the outlier here, because that base is only aimed at the current library.

The original argument was that sealed was mutually exclusive with interface, final and base because it already restricted other libraries as much as any of them, so adding sealed to another modifier wouldn't change anything.
That's not entirely true after we made base be contagious, a sealed base has a different effect than just sealed inside the same library too. Not an effect you can't get anyway, by manually putting base on all subclasses, but nevertheless a difference.
Still, the extra modifier only affects the current library, and we generally considered modifiers as relevant to other libraries.

I'd be very surprised to ever see sealed final class being considered useful, because a final aimed only at the current library makes no sense for a class that must be subclassed to be useful. There is no difference between sealed base and sealed final in effect (both currently requires subclasses to be base-or-more, and does nothing more inside the same library, and the sealed prevents the declaration from being used from outside of the library.)

And sealed interface is nothing but documentation, it has no effect whatsoever. Being interface doesn't restrict direct subclasses in the same library in any way, or transitive subclasses at all, and sealed prevents direct subclasses in other libraries, so the interface modifier has zero effect on anything.

That is: sealed base or sealed final has one effect: It forces immediate subclasses in the same library to be base. We only need one, and base is the more reasonable one since there will be subclasses. So the only combination which can reasonably be argued for is sealed base.

I can see sealed base class and sealed interface class being allowed as documentation, but not really for effect.
(sealed mixin and sealed mixin class are more directly useful.)

The argument for allowing these anyway would be orthogonality, so that if an author chooses to write it it, we can say that it works as they (hopefully) think it does, and then recommend that they remove the unnecessary words.

[rrousselGit]

For reference, I personally have a usecase for sealed mixin class.

I have a code generator which wants the annotated class to be declared as "mixin" because the generated code uses "with". But I also want to enable the class to be marked as sealed.

[jakemac53]

(Because you always have all the capabilities inside the same library, without doing anything.)

Well that isn't entirely true, because base is still contagious within the current library. If everything else can be violated in the same library without any explicit action that seems unfortunate tbh, but the ship has sailed.

I understand we are also considering dropping the contagiousness of base in the current library but I hope we don't do that, or at least require some explicit marker to do it instead of implicitly allowing it.

[munificent]

We made a deliberate choice to not have class modifiers that let you control capabilities within a library. It's entirely reasonable and meaningful to have them, but it means even more modifiers and more combinations and more complexity. Since a library is all "your code" anyway, I don't think modifiers or combinations of modifiers that are only helpful within a library carry their weight.

I think of a library as the "unit of maintenance". If your library is so complex that you need to start using language features to enforce invariants within it in order to maintain it, that's a hint that you might want to split it into multiple libraries. (Though I realize sealed does interfere with that.)

For sealed base in particular, I think it isn't worth it because it adds so much confusion to users outside of the library. If they see a class marked base, we want them to think "I can extend this". But in this case, the sealed would cancel out the meaning of the other modifier. This is the same reason we disallow sealed mixin. That combination has entirely valid semantics that are even potentially useful, but it's just really confusing outside of the library because it says mixin but you can't mix it in.

[rrousselGit]

Note that my personal use-case for sealed mixin is code-generators.

I expect the input of my code-generators to be "mixin" classes. This is necessary because I have some multiple-inheritance scenarios, where "extending" the annotated classes won't be possible.
But I also want to support sealed class at the same time.

I don't see how I could do that without sealed mixin.

[rrousselGit]

In code, this means I want folks to be able to write:

@freezed
sealed mixin class Example implements _$Example {
  factory Example.a() = A;
  factory Example.b() = B;

  void doSomething()  => print('Hello');
}

@freezed
sealed mixin class Another implements _$Another {
  factory Another.a() = A;

  void anotherMethod() {}
}

where A/B are code-generated and ends-up being:

class A with Example, Another {}

clas B with Example {}

which enables:

switch (Example.a()) {
  case A(): print('first');
  case B(): print('second');
}
...
A()
  ..doSomething()
  ..anotherMethod();

[jakemac53]

Since a library is all "your code" anyway, don't think modifiers or combinations of modifiers that are only helpful within a library carry their weight.

I disagree wholeheartedly with this assertion. Libraries are not written by a single person who maintains them forever. And even if they were, when you come back to your own code years later you won't remember anything about it anyways.

The more assumptions/intentions about my code that I can express statically as opposed to in a comment that nobody will read, the better.

I think of a library as the "unit of maintenance". If your library is so complex that you need to start using language features to enforce invariants within it in order to maintain it, that's a hint that you might want to split it into multiple libraries. (Though I realize sealed does interfere with that.)

I don't think the language should be designed in such a way that it assumes all libraries are small. There are valid reasons to have larger libraries, in particular sealed is a good example, we essentially force large libraries.

For sealed base in particular, I think it isn't worth it because it adds so much confusion to users outside of the library. If they see a class marked base, we want them to think "I can extend this". But in this case, the sealed would cancel out the meaning of the other modifier.

I really don't think this is confusing, base doesn't mean "can be extended" - all classes can be extended by default. All modifiers other than mixin impose restrictions on usage. Those restrictions compose together totally sensibly in this case: base means it can't be implemented and sealed means all direct subtypes are statically known (and defined in the same library). What this tells you is all the sealed subtypes can themselves only be extended due to base transitivity.