Adding a new design constraint to D

[forkit]

So there has been extensive discussions in other threads, around 
the idea of adding a new 'design constraint feature' to the D 
programming language.

The design constraint feature, is 'designed' to allow the 
programmer to make an explicit declaration, that some aspect of 
the design of a class, should be private to that class, and 
thereby make that aspect of the class (logically) inaccessible to 
code outside of that class, but in the same module.

The constraint could, in theory, apply to other types such as 
struct or enum. But the suggestion currently relates to the class 
type only.

The below example compiles just fine, as you would expect.

// ------
module test;
@safe:

class someClass
{
     private:
         string _id;

     public:
         void setID(string id)
         {
             // some condition(s), if met, then:
             _id = id;
         }
}

unittest
{
     someClass myclass = new someClass();
     myclass.setID("123");
}

// -----

Is the above code consistent with the design intent of someClass?

The answer must be yes, since in D, private is private to the 
module.

But what if the intent was to require other code to 'use the 
inteface' to access x?

The problem is, many coming to D, come from languages where you 
can already declare such an intent, and equally importantly, have 
that intent enforced by the compiler, at compile time.

But the D programming language has no feature to declare such an 
intent. So where does this leave those programmers?

The argument has been made, that D does not need such a feature, 
because scope is always at the module level.

But it does not follow, that scope at the module level eliminates 
the need for such a feature. That argument is not logical.

The next response, is that if you need this feature, then you can 
'simulate it' by putting the class that needs this feature, into 
its own module.

However, the one-class-per-module approach, imposes its own new 
design constraint, and not one the programmer necessarily makes 
of his/her own volition.

It also does not necessarily follow, that a class in its own 
module, is there for the purposes of stipulating this constraint.

There are any number of a reason, why a class might be put into 
its own module. You cannot infer anything from that. You'd have 
to speak the designer to know intent.

Other arguments have also been made against adding such a 
feature, but it is difficult to take them seriously - such as 
'why would a class ever need to hide something'.

Now the advantage of adding such a feature, is that it provides 
private at the scope level for those who want or expect such a 
feature, it provides evidence of the designers intent to separate 
implementations from interface, and the compiler which now knows 
the intent, can enforce that intent, at compile time.

So the only logical outcome of this discussion, is whether the 
benefit of adding a design constraint *option* to the language, 
outweighs the cost of adding it to the langauge.

The benefits of adding this feature appear to be self-evident.

So ultimately, this comes down to a benefit-vs-cost consideration.

The cost of adding it to the language, is less self-evident.

Is the cost, the unjustified cognitive burden of having both 
'private' and 'private(scope)', instead of just 'private'?

Is the cost - it's just too complicated to change the compiler 
source to accomodate this option?

What do you think the cost of adding such a feature is?