In theory, there is benefit to having local sealed interfaces, in that
they would provide a source of exhaustiveness information for switches
inside the method. On the other hand, we don't really want to encourage
methods to be enormous. So at least for now, this fix seems fine.
On 8/18/2020 7:15 PM, Vicente Romero wrote:
Hi Remi,
On 8/17/20 10:07 AM, Remi Forax wrote:
I've found a discrepancies in the current spec of sealed,
the current spec allows local sealed interface but you have no way to
provide a sub-types apart a sealed sub interfaces.
A record or an interface is allowed to be declared inside a method,
by example, this is a valid code
static void foo() {
interface I {}
record Foo() implements I {}
}
the interface can also be sealed
static void foo() {
sealed interface I {}
record Foo implements I {}
}
but this code does not compile because Foo is a local class and a
local class can not implement a sealed interface.
This rule was intended to not allow this kind of code
sealed interface I {}
static void foo() {
record Foo implements I {}
}
because the interface I is visible while Foo is not.
But we have forgotten to discuss about the case where both Foo and I
are in the same scope.
I see two possible fixes
- disallow sealed local interfaces
+1 having a local sealed class seems like unnecessary, this option
makes more sense to me
- allow local class/record to implement a sealed interface if they
are in the same scope.
Rémi
Vicente
