Wed Oct 17 - Avoiding Code Smells by Walter Bright

[Neia Neutuladh]

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.