Adding a new design constraint to D

[forkit]

On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>
> Consistency is a worthy goal, but as I explained in my recent 
> Code Europe presentation, too much consistency leads to 
> undesirable results, too.
>
> For example:
>
>     for (int i = 0; i; ++i);
>     {
>         ...
>     }
>
> D adds grammatical inconsistency to reject that.
>
> And then there's that famously inconsistent symbol table lookup 
> that D does that everyone but me insisted is intuitive :-)

I'm not sure consistency with C, is necessarily a worthy goal.

Of course you've demonstrated that in your for loop example (i.e. 
a good reason for D to not be consistent here).

I can easily understand your reason for wanting to be 
inconsistent here. I've made this mistake numerouse times myself, 
as I'm sure many others have.

What I cannot understand, is your refusal to allow a class to 
declare something private to the class. I'm not aware of 
programmers making mistakes because they declared something in a 
class to be private. If the made a mistake, it's a design 
mistake, not a mistake of being able to declare something private 
to a class.

What is the rationale for this inconsistency in D?

The only explanation I've ever seen from you, on this issue, is 
that "in D, the module is the unit of encapsualtion". But that is 
not a rationale for being inconsistent here.

What is the rationale?