Code That Says Exactly What It Means

[Peter C]

On Tuesday, 28 October 2025 at 16:26:57 UTC, Max Samukha wrote:
> On Tuesday, 28 October 2025 at 13:25:42 UTC, jmh530 wrote:
>> On Tuesday, 28 October 2025 at 02:28:41 UTC, Walter Bright 
>> wrote:
>>> I know you didn't propose this, but I had quite enough of 
>>> C++'s "friend" classes. I've never missed that misfeature in 
>>> D.
>>
>> You are correct on this.
>
> He's been attacking a strawman. Nobody asked for friend 
> classes. People have been asking for the ability to restrict 
> access to non-friend class members inside a module. Even Rust 
> gives you that by allowing struct implementations in in-file 
> submodules.
>
> (Dislaimer: I don't care about "class-private".)

I think that 'Disclaimer' misses the point of this thread.

In my view, the [internal aspect of a] module should represent a 
'collaboration boundary', not an 'ownership boundary'.

That is the real distinction I'm trying to make.

This is where different perspectives should take their positions.

It just so happens that I'm using a class type here, but it could 
be any type.

One side of the argument is: If you put related types in the same 
module, they should own each other.

I say no - actually, I put them in the same module because they 
needed to collaborate much more closely than they would be able 
to if they were not in the same module. But they certainly do not 
need to own each other.

I have not seen any valid argument, for why 'they should own each 
other'.