Module-level privacy

[Neia Neutuladh]

On Sunday, 13 May 2018 at 02:36:28 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 02:10:31 UTC, Uknown wrote:
>> And please, if this bothers you so much, start a new thread. 
>> You're spamming someone else's feature request by going off 
>> topic.
>
> yeah, I know how much *you* (and many others) would like to 
> shutdown any discussion about the absurd way in which classes 
> are treated in D. It's a touchy topic it seems.

Nobody's getting worked up about this, and nobody's telling you 
to stop talking about it. There have been suggestions that you 
write up a DIP for it. This is a standard process for suggesting 
improvements to D.

I have a draft DIP hanging around on my hard drive relating to 
named function parameters, for instance. It discusses:

* The thing to be changed
* Why I think it should be changed
* Examples of how the status quo causes problems
* How I want code to work in the future
* Examples of what I want code to look like
* How other languages handle this thing

That's just due diligence for nontrivial enhancement requests. 
And named function parameters is a feature with probably very 
little opposition and moderate support.

> so take your own advice. create a new thread, and have a go at 
> me there instead.

It should be as easy as changing the "Subject" field on the reply 
screen. It would have been gracious of you to do this, all things 
considered.

> When someone creates a topic about extending the capacity of 
> classes in D, I will always feel the urge to remind them, that 
> classes in D are a complete joke - and that you shouldn't 
> bother using them. Better to use another language that has the 
> capacity to respect the encapsulation barrier of the class.

Your complaint is about protection, not about classes. It should 
affect all definitions. Perhaps you simply don't expect 
type-level encapsulation for structs and top-level declarations.