Adding a new design constraint to D

[forkit]

On Sunday, 19 June 2022 at 11:19:43 UTC, Max Samukha wrote:
>
> ...
> And the nonsensical debates like 
> https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/#comment-6546 wouldn't have happened, if D had done the most reasonable thing from the start - make 'private' mean 'private to the current scope'; provide 'private(ancestor)' for choosing the encapsulation boundary; and maybe provide shortcuts for module and package. That's it. No need for articles trying to justify the arbitrary imposition.

Additionally, in the comments of that article, Jim Balter uses 
the Ceylon Language in his argument against the idea of allowing 
scope level privacy within a module.

But looking at the Ceylon Language docs, I see they already made 
the argument for me ;-)

"Of course, we could have chosen to make shared visibility the 
default, providing a private annotation to restrict access. But 
that would have been very harmful to modularity, a key goal of 
the language.

The "best" default is the most restrictive option. Otherwise, the 
developer of a module might accidently make something shared that 
they don't intend to make shared, and be forced to either 
continue to support the unintentionally-shared operation for the 
rest of the life of the module, or break clients. There would be 
nothing the compiler could do to warn you when you accidently 
left off a private annotation."

https://ceylon-lang.org/documentation/1.2/faq/language-design/