Module-level privacy

[bauss]

On Sunday, 13 May 2018 at 05:51:07 UTC, KingJoffrey wrote:
> On Sunday, 13 May 2018 at 05:11:16 UTC, Neia Neutuladh wrote:
>> 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.
>>
>> 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.
>
> First, this thread was about extending the capabilities of 
> classes in D with some new attribute/capability - sealed.
>
> I thought it was first important to point out, in this thread, 
> as opposed to a separate thread, that classes in D are already 
> problematic, because modules do not respect the encapsulation 
> boundaries of classes, and any discussion about further 
> extending classes should be approached with great caution - 
> because the problem will only become even more entrenched.
>
> Second, writing a DIP is pointless, since Walter likes the idea 
> that the module doesn't protect the encapsulation boundary of 
> the class. Now if Walter thinks that's fine, what is a DIP 
> going to do? I mean really. I have better things to do.
>
> Third, those who responded to my caution are the ones that 
> should have created a separate thread, not me.
>
> Finally (and I do mean finally), my concern about the loss of 
> the encapsulation boundary of classes in D, has a very real 
> impact on the quality and maintainability of software systems 
> developed in D. That the designer of D apparently thinks 
> otherwise, baffles me.

Walter is not the only person who accepts DIP and although he's 
the core head of D, it doesn't mean all his opinions are strictly 
100% how D is going to evolve. I'm sure there are plenty of 
features that has been implemented that he does not entirely 
agree with and the same goes for others.

If you can write a DIP and have a good use case for it, other 
than a very rare usecase, then it would most likely be accepted, 
IF the language would benefit from the addition.

Writing posts about how you don't like feature X is way more 
useless than a DIP, because it will NOT change anything.