Sealed classes - would you want them in D?

[rikki cattermole]

On 11/05/2018 3:18 AM, Bastiaan Veelo wrote:
> On Thursday, 10 May 2018 at 13:22:20 UTC, Piotr Mitana wrote:
>> Hello,
>>
>> I've recently thought of sealed classes (sealed as in Scala, not as in 
>> C#) and am thinking of writing a DIP for it. I decided to start this 
>> thread first though to gather some opinions on the topic.
>>
>> For those who never coded Scala and don't know sealed classes: a 
>> sealed class is a class which can be only extended in the same source 
>> file.
>>
>>     sealed class MyClass {}
>>
>> Translating to D, a sealed class would could only be extended in the 
>> same module. Additionally I would suggest "sealed(some.package) 
>> MyClass {}" syntax for classes that could only be extended in the 
>> particular package.
>>
>> In Scala an important value of sealed classes is that compiler knows 
>> that and can aid programmer in pattern matching by detecting the 
>> missed cases. However, there is another value I see: limiting the 
>> extension of classes.
> 
> [...]
> 
>> Combining sealed with final library developer can create a completely 
>> closed type hierarchy.
>>
>> Any thoughts on that proposal?
> 
> How about extending the behaviour of ‘private’, which means private 
> except for this module, to ‘final’, which would then allow sub typing in 
> the same module but not outside? It would not break any code. Are there 
> downsides to such a change?

You can already sub type with private. What you can't do is sub type 
with both private and final. It should remain this way.

Let's not go changing semantics of already understood language features. 
Exceptions to rules are not ok, nor will they be approved.