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

[Steven Schveighoffer]

On 5/16/18 10:32 PM, 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 you are going to get this to fly. We already have 
abilities to make the details truly private. I agree it's not as 
straightforward as other languages, but it is possible. Lately, the 
chances of adding an enhancement like this is pretty slim -- we have a 
mechanism to do it already, but is just a little more clunky. And it's 
not a huge problem for most code. I'd predict that if this were to be 
accepted, it would seldom be used anyway. So the cost/benefit ratio is 
very high.

Essentially, if you put your class you want "sealed" into it's own 
module, and then publicly import the module from the API module, you 
will get the same effect. This is even easier now with the package 
module than it used to be.

What private currently does is rational and makes sense. It's not the 
same as all other languages, but it is the same as some of them. It's 
simply a preference, and D picked something different from what you 
like. There are things I would have picked differently than D also, but 
not much to be done about those choices at this point.

-Steve