Non-ugly ways to implement a 'static' class or namespace?

[ProtectAndHide]

On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
>
> We keep repeating the same arguments over and over and over 
> again on this. I still haven't seen any convincing argument for 
> changing things when it's already possible to do what you want 
> to do. I repeat for the umpteenth time: if you care so much 
> about who can touch your private parts, then put your classes 
> and structs in their own modules and use D's package facilities 
> to provide the public interface you want.

The convincing arguement (convincing to me anyway) was made when 
I came to D, programmed a class, and put a unittest in the same 
module, and accidently referenced hidden data of my class in my 
unittest. This result in a bug. It was when i was tracking down 
the source of this bug, that I discovered that private is not 
private at all (inside the module).

If there is a cycle continuing, it's because your solution to a 
'real' problem (read above again please), is to force an 
unreasonable design constraint onto the programmer.

This includes being forced to put your unittest in its own module 
as well (for reasons demonstrated above).

It should be up to the programmer to decide what types should go 
into their module: Not the language! You think the language has 
this right to force such a constraint onto the programmer, I do 
not. That really is the basis for the disagreement here.

I want fewer modules, each containing tighly couple types.

You want more modules, each containing one single type.

I want unittest in the same module as my type.

You want me to have them in their own module as well.

No. I cannot accept this as a reasonable solution.