Adding a new design constraint to D

[forkit]

On Sunday, 19 June 2022 at 09:46:40 UTC, Sergey wrote:
> On Sunday, 19 June 2022 at 08:12:28 UTC, forkit wrote:
>> On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>>>
>> What is the rationale?
>
> Just leave it here, to be sure, that every participant of the 
> thread have seen this:
>
> https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

So am aware of this article, of course.

It explains why 'everything is global' in a module - in essence, 
to be able to encapsulate classes and 'free' functions in the one 
place, and thereby avoid the need to have C++ like 'friend'.

Fine. I don't reject that argument.

What I reject (and what the article does not address), is not 
having an 'option' to 'unfriend'. What is the rationale for that?

Not having that option, means you cannot restrict access to an 
object through the set of operations as specified by that type. 
That means, you've lost the essential capacity for using the 
class as a means of data abstraction.

In D, the class is not a data abstraction anymore. It's just one 
'thing' in the larger module abstraction.

As I've said before, in D, you cannot put "wtf" into an int. The 
int is a data abstraction with defined invariants that the 
compiler will enforce.

I just wanted an option, so that my class type could have its 
invariants explicately declared, and  enforced by the compiler, 
and not have to worry, that someday, someone, maybe even me, 
might end up putting "wtf" into my int.