On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote: > (q1) Why is it, that people who use D, object *so much* to the idea of > allowing (at the choice of the programmer) for a type to have it's own > private state *within* a module (so that its private state is respected > by other code also within that module)?
We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them. We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you. > Or you ask it another way: > > (q2)Why must a type within a module *always* have its private state > exposed to other code within the module? (the key word here, being > 'always'). Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list. > (q3) Should a language intentionally set out to prevent a programmer > from making that choice? You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.
