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

[Gheorghe Gabriel]

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:
> On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:
>> On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:
>>> On Friday, 18 May 2018 at 15:40:52 UTC, KingJo
>>>
>>> class A {
>>>    private int x;
>>>    private(this) int y;
>>> }
>>>
>>
>> I agree that this looks a bit strange.
>> My initial proposal was "sealed" instead "private(this)" today.
>
> Mmm.. that brings me back to the idea of sealed at the class 
> level again.
>
> class A

> {
>    private int x;
>    private(this) int y;  // imagine if you have lots of private 
> variables.
>                          // this could become pretty anoying - 
> and kinda redundant.
> }
>
> class A
> {
>    private int x;
>    sealed int y; // again, what if you have lots of private 
> variables that
>                  // that you really want sealed.
> }
>
>
> // Now. Back to the idea of sealed.
> // abosolute consistency of your private variables.
> // no redundancy.
> // no some 'private', some 'sealed' confusion.
> // no some 'private' (but really public) some 'private(this) .. 
> confusion.
> //
> sealed class A{
>     private int x;
>     private int y;
> }
>
> downside, is adding a new keyword, and getting agreement on 
> what that new keyword should be.
>
> So I've come full circle again, and believe my idea is worth 
> further consideration.

If you have
sealed class A {
    private {
        // members
    }
}
Then you can't use the defualt 'private' if you need it for a 
specific member.

But if sealed is an access type of a member, 99% you will use 
sealed insted private in a class, so it is not redundant.

class A {
    sealed {
        // members
    }
    private int friendMember;
}

And you use private keyword only if you need to access that 
variable from a class/function/struct.. in the same module, like 
a friend.