Sealed classes - would you want them in D? (v2)

[Piotr Mitana]

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
> I propose an idea, for discussion (robust discussion even 
> better ;-)
>
> Add an new attribute to class, named 'sealed'.
>
> No, not sealed as in Scala.
>
> No, not sealed as in C#
>
> sealed as in oxford dictionary (close securely, non-porous).
>
> when sealed is applied on the class, this means the class is 
> sealed.
>
> the sealed attribute only makes sense within a module, and 
> affects nothing outside of the module.
>
> When sealed is applied to the class, then, interfacing to a 
> class within a module, from code outside that class - but still 
> within the module, can now only occur via the published 
> interface of the class.
>
> outside code in the module, can no longer directly access your 
> private parts!
>
> The class is sealed.

I don't think that "sealed" is the right name here. Currently C# 
has its sealed and Scala has its sealed - and these are different 
things (although I don't code C# and may be wrong, it seems like 
C#'s sealed is Java's or D's final). I believe that giving 
"sealed" keyword yet another sense in D is not the right approach.

Furthermore, I don't believe that the proposed version of sealed 
would be a widely-used feature that broadens the language 
capabilities. It solves the problem that - as discussion in my 
thread shown - some people consider valid, and some not.

My opinion is that it's not worth a new keyword and time for 
implementing. In the same manner you could ask for removing 
friend concept from C++ as a bad concept. I don't answer the 
question whether this concept is good or bad - just give an 
example. The difference is that you can just go without friend at 
all, and module-level private is forced.

The other reason I don't think it is a feature significant enough 
is kind of library level. I expect that only author or limited 
team of people will freely modify the code of module. So there is 
limited number of people that have a control over the module and 
it shouldn't be a big deal not to refer to private fields outside 
the class or define it as a team rule. I believe that a nice 
approach here would be to add a check to DScanner, so that your 
editor or IDE could optionally warn you if you refer to the 
private member from outside the class. But as module is a small 
unit and its code should probably be controlled/verified by the 
limited number of people, I don't see this as a big deal.

Note that Scala-like sealed from my proposal would have a greater 
impact (it blocks inheritance outside the module - helps to 
prevent the library code from being used in a way it is not 
designed to) and your proposal changes things in a very limited 
scope.

OFC, I am not a "compiler person", nor Walter, Andrei and anyone 
from the team, so my opinion is definitely not decisive in any 
way :)

To sum up [TLDR]: I don't see your arguments strong enough to 
alter the language (especially make a cross-language confusion 
over the "sealed" keyword), but DScaner check would still allow 
to track down what you consider bad.