Open mraleph opened 1 year ago
Why the "case" keyword instead of "class"?
@rrousselGit it makes a clearer connection to the surrounding class. class
within a class
does not convey the same meaning. case
makes it clearer.
Talk about timing: @eernstg has just uploaded primary-constructors proposal (which I knew was cooking, but could not find anywhere to refer to).
I have now reworded original proposal to simply delegate to primary-constructors syntax.
Like switch
removed case
:
switch(aInt) {
1: print('1'),
_: print('not 1'),
}
Couldn't we just omit case
like:
sealed class Result<T> {
Ok<T>(final T value);
Error(final String message);
}
or that collides with current grammar? I think it's fine to assume that a class declaration inside a sealed
class is a case.
@rubenferreira97 the syntax you propose is valid today and defines two abstract instance methods.
@rrousselGit it makes a clearer connection to the surrounding class.
class
within aclass
does not convey the same meaning.case
makes it clearer.
Would we be able to use all the class syntaxes though? Like mixins, abstract/final/sealed/internal, implements/extends, ...?
If so, I'd prefer using "class". I think the nesting would be enough to communicate the relationship.
Just to add that in the future possibility of Dart adding data class
es, the syntax case data
would be strange. Kinda the same problem with modifiers that @rrousselGit described.
sealed class Result<T> {
data class Ok<T>(final T value);
data class Error(final String message);
}
Also what about two-level nesting?
Like:
sealed class A {
sealed class B {
class C {}
class C2 {}
}
class B2{}
}
I'm definitely interested in some better syntax in this area, yes. The main challenges that I know of are:
Users have also requested static nested classes (#336). I think that's also a useful feature, so I'd like to make sure whatever syntax we come up with doesn't collide with that.
As @rrousselGit suggests, it would be nice if this extended to support entire sealed hierarchies and not just a single level deep.
The subtypes of a sealed supertype might implement or extend it and it would be nice (but not strictly essential) to support being able to express both of those.
I think those are likely tractable, but it will take some work to sort out.
With
sealed
class families and pattern matching developers are understandably excited to use them for data modelling in their programs. However the syntax is overly verbose for simple families, e.g. modelling success / failure in the API requires writing something like this:With primary constructors this is reduced to
Which is much better but still has some repeated boilerplate here: repeated
extends Result<*>
.I suggest expanding upon primary constructors and introduce a special syntactic sugar for simple sealed families like this
Here
case C<T1, ..., Tn>(v0, ..., vN) { m1 ... mN }?
occurring insidesealed class B<U1, ..., Un>
gives raise toForward(...)
is defined as forwarding type parameters based on their names (or maybe indices - I am not sure what is better). IfUi
does not have a correspondingTi
thenNever
is passed instead./cc @munificent @lrhn