`restricted` member variables

[forkit]

On Thursday, 23 June 2022 at 00:05:24 UTC, Paul Backus wrote:
>
> If you actually look at the quote in context, what Stroustrup 
> is describing is essentially the PIMPL idiom, where the 
> representation of an abstract data type is made entirely opaque 
> to the code using it. This opaqueness is what leads to the 
> shortcomings Stroustrup describes.
>
> D's modules do not work like this, and thus do not suffer from 
> those shortcomings.
>
> Here is a link to a freely-available PDF of the linked paper, 
> on Stroustrup's own website, for anyone else who would like to 
> read it:
>
> https://www.stroustrup.com/whatis.pdf

so the paper is actually about the features needed to support the 
use of proper types, on which OOP techniques depend.

the success of both, depend on the design of the types.

the design of the types depend on the features available to 
define those types.

data hiding is an important feature in his argument (as are other 
features).

private(this) enables data hiding *within* a module.

you now have the tool needed to define an abstract data type 
*within* a module.

you are now longer constrained to one class-per-module.

you now have compiler your side, cause it too knows your intent.

it can enforce that intent

it can use that intent to potentially optimise (inline etc..)

it's completely optional to use.

I fail to see the downside (providing the syntax fits in well 
with the rest of the language, and doesn't stand out like a sore 
thumb).

once it's in, people will use it, or not, and all this fuss will 
be long forgotten....