`restricted` member variables

[forkit]

On Wednesday, 22 June 2022 at 23:48:22 UTC, deadalnix wrote:
>> ```
>>
>
> This is a good starting point.
>
> Yes, Other will be able to manipulate VLA's innard in this 
> exemple. Now there are two questions that immediately come to 
> mind:
> 1/ Should it be able to? From this limited example, it's hard 
> to tell, but there is no need to be pedantic so we'll assume 
> that yes it does. You'll note that this is not obvious per so, 
> Other might be a view on the VLA for instance.
> 2/ If 1/ is true, then do they really belong in the same module?
>
> I think 2/ is the question that is being skipped there, because 
> the very characteristic of a module is to be the place where 
> all the element it contains are implemented. If it is capital 
> that Other is not exposed to the innard of VLA, then is it hard 
> to defend that implementing them both together in the same 
> place is the right design choice.
>

shouldn't 'what goes in a module' be the choice of the programmer?

why does it have to be something enforced on the programmer, by 
the language?

the problem with the D module, is that enforces on all 
programmers, that IT is THE MASTER abstract data type to rule 
them all, and all others shall bow to it.

Sorry, but no! My types will NOT bow.

In fact, not even an int in D bows to that demand. Why should my 
types?