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

[KingJoffrey]

On Saturday, 19 May 2018 at 21:25:37 UTC, 0xEAB wrote:
>
> I wouldn't consider putting classes into own modules a 
> workaround. In my opinion it's more or less the solution.

I'll add your solution into my article - but, I'm not sure it 
really addresses my problem statement.

The Problem Statement (being drafted still):
---------------------
In the D programming language, the semantics of the access-level 
modifier 'private' is likely very different to what a large 
number of programmers from object-oriented, and class-oriented 
languages, might expect.

In D, the module (not the class) is the overarching entity, and 
one that encompasses all other entities within the module.

In D, The module can contain (and typically would contain) a 
variety of types - functions, structs, classes and so on.

If a module contains a class type however, and that class has a 
private access modifier on it's members, then that private access 
modifier becomes moot (within the module), because all the 
surrounding code in that module can directly access (and even 
modify) those private members.

The module implicitly morphs a 'private' access modifier, into a 
'private-but-also-module-public' modifier.

The programmer has no control over this implicit conversion of 
the access modifier.

This would be unfamiliar, and unexpected, to a very large number 
of programmers from languages where 'private' has an established 
and well-defined semantic as being the most restrictive form of 
access to a class member.

Unfortunately, in the D programming language, there is simply no 
way to declare a member of a class to be private, and prevent 
surrounding code (within the module) from accessing it.

The D module, will implicitly change the semantics of your code.


The Implications:
----------------
..to do....