`restricted` member variables

[deadalnix]

On Thursday, 23 June 2022 at 09:42:59 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 23 June 2022 at 09:30:49 UTC, deadalnix wrote:
>> Usually, while you increase things on one axis, you also 
>> diminish them on another.
>
> I don't see how providing more expressive constraints diminish 
> anything on a semantic level if sound.
>
> There is an implementation/design/educational cost, but history 
> suggests that languages over time add more expressive 
> constraints: C++ concepts/consteval, Python typing module, 
> TypeScript, JavaScript classes/private.

Then you see how providing more has a cost, at least and 
`implementation/design/educational` one. So there is a point at 
wish adding that expressivness is counter productive, it is at 
the point when the value of the extra things that you can express 
is lower than the cost incurred by implementing the change 
required for that extra expressivness to be possible.

There are other costs:
  - Tooling will not support that feature initially. D tends to be 
cavalier with that, and as a result, has worse tooling than 
pretty much any other language out there.
  - There are now many ways to express the same thing (put things 
in different module and use `private` or put thing in the same 
module and use `private(this)`). This has an adverse effect on 
readability by providing ways to subvert the expectations of the 
reader.

I'm also convinced that there are costs I cannot really pinpoint, 
but that are real. The existing landscape clearly demonstrate 
this. For instance, while Java provides class level visibility, 
it is actually commonplace to have one Java class per file in 
numerous projects.  Amongst the top languages, more than half 
have little to no visibility constraints, and these who do like 
Java tend to have idioms to map visibility with files.

There is something there that remains under explored.