Adding a new design constraint to D

[JG]

On Tuesday, 14 June 2022 at 05:43:49 UTC, forkit wrote:
> 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?

I think you are missing part of your analysis. Is this a complete 
feature you are suggesting to be added? I also haven't thought it 
through to the end but for instance wouldn't something like 
"friend" need to be added shortly after adding this?

Another point that you are perhaps missing is that each person 
who uses D probably has at least one thing they would like added 
to the language (which they consider to be extremely important). 
If all these things were added, D would be much more complicated 
than it is now, even if each is a minor change.

In reading what you wrote I didn't find the following clear:

> 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.