I agree its reasonable, but I don’t think the spec quite allows it yet, so
we’ll put that on the list of things to be refined.
> On Oct 12, 2019, at 12:53 PM, Tagir Valeev <amae...@gmail.com> wrote:
>
> Yes, I just wanted to draw attention to this detail. The current spec
> draft doesn't cover this case explicitly. I agree: this solution is
> reasonable.
>
> With best regards,
> Tagir Valeev.
>
> On Fri, Oct 11, 2019 at 9:07 PM Brian Goetz <brian.go...@oracle.com> wrote:
>>
>> This seems reasonable to me. So, spec consequences:
>>
>> - sealed, non-sealed illegal on enums
>> - enums can implement sealed types
>> - said permission to extend pushes down to constants, including the
>> anonymous classes of nontrivial constants
>>
>>
>>
>>> On Oct 11, 2019, at 6:59 AM, Maurizio Cimadamore
>>> <maurizio.cimadam...@oracle.com> wrote:
>>>
>>> I think an enum declaration is 'morally final' in the sense that, while it
>>> can't really be marked with ACC_FINAL (because there might be constants
>>> which extend from it), the user cannot subclass the enum. Everything weird
>>> you can do with an enum, remains _inside_ the enum declaration bubble,
>>> which I think makes mixing enums and sealed interface pretty safe. It is
>>> also lucky that we can't say 'final enum' - meaning that I would also
>>> extend it to the other keywords - that is, you can't put sealed, non-sealed
>>> on an enum.
>>>
>>> Regarding the 'anonymous enum constant' issue you raise how is that
>>> different from:
>>>
>>> sealed interface Y permits Bar, Baz {}
>>>
>>> class Bar implements Y {}
>>>
>>> ... new Bar() {}
>>>
>>> In this case, I don't think you break exhaustiveness in the same way you do
>>> if you allow anonymous implementations of Y.
>>>
>>> Clients will be assuming that Y is either a Bar or a Baz, and the fact that
>>> some of the Bars are anonymous instance is immaterial to this.
>>>
>>> Unless I misunderstood what you were trying to say. If not, I think my
>>> reasoning here would be to:
>>>
>>> 1) allow enums to implement sealed interfaces
>>> 1b) do not allow sealed, non-sealed modifiers on an enum (e.g. do the same
>>> as with final)
>>> 2) allow anonymous enum constants inside the enums in (1) - as they can't
>>> break exhaustiveness for clients
>>>
>>> Maurizio
>>>
>>>
>>> On 11/10/2019 04:02, Tagir Valeev wrote:
>>>> Hello!
>>>>
>>>> Sorry if this was already discussed, but what about enums extending
>>>> sealed interfaces? E.g.:
>>>>
>>>> sealed interface X permits Foo {}
>>>> enum Foo implements X { // can we do this?
>>>> A {}, // and what about this? Here we have an additional subclass at
>>>> runtime. Or we should explicitly declare "non-sealed enum Foo" to
>>>> allow this?
>>>> B,
>>>> C
>>>> }
>>>>
>>>> With best regards,
>>>> Tagir Valeev.
>>>>
>>>> On Thu, Oct 10, 2019 at 3:46 PM Maurizio Cimadamore
>>>> <maurizio.cimadam...@oracle.com> wrote:
>>>>>
>>>>> On 10/10/2019 01:50, Brian Goetz wrote:
>>>>>> Right. We already restrict anon and lambda instances of the sealed
>>>>>> type. Not only can't we stably write down their types in the PS
>>>>>> attribute, but even if we could, it's so easy to accidentally lose
>>>>>> exhaustiveness.
>>>>> This is a very good point; if I have type T = A | B | C, but then I have
>>>>> 'anonymous' Ts flying around, all switches assuming A|B|C are no longer
>>>>> exhaustive.
>>>>>
>>>>> Maurizio
>>>>>
>>
