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

[aliak]

On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:
> private(this) int y;
>
> This keeps the implementation simple and the scope focused.

Yeah, maybe more focused at the beginning would be better. A 
comma separated list can be added later if deemed worthy.

And agreed, the java recommendation might help build a case. 
There's also the argument of avoiding state related bugs in 
larger code bases that is managed through computed properties:

class A {
   @property int i() {
     // fix internal state due to access
     return _i;
   }
   private int _i;
}

Of course these are all solved by putting a class in its own 
module anyway. I can see this being problematic the bigger code 
bases get though. I.e. programmer A adds an extension function in 
module M that is 6000 lines long and doesn't see that he should 
do A.i and not A._i - bug maybe goes unnoticed for long time.

Only thing I can actually think of is if you want to have 
extension functions on classes in the same module and only want 
some variables to be accessible from extension functions but keep 
other truly private, you can't do this. So it makes writing code 
in an extension based style harder. But then you can argue if an 
extension needs to access private(this) variables then it should 
be module private anyway. So meh...