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?

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.

On Tuesday, 14 June 2022 at 06:09:57 UTC, JG wrote:
>
> 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?
>

No. I cannot see how such a concept (of needing to add friend) would ever apply here??

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

This may be a valid reason for not adding 'any' new feature, but it is not a valid reason for not adding 'this' feature.


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

Putting one class in a module by itself, means no other code except that class is in that module, and therefore the class does not need to 'hide' anything from any other code in the module - cause there isn't any other code in the module.

But putting one class in a module by itself, demonstrates no intent whatsoever.

You have to ask the designer why they chose to do that.

The option suggested would 'explicately' specify an intent, and can do so *without* enforcing a one-class-per-module design constraint onto the programmer.

On Tuesday, 14 June 2022 at 06:43:36 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 06:09:57 UTC, JG wrote:
>>
>> 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?
>>
>
> No. I cannot see how such a concept (of needing to add friend) would ever apply here??

So there is no use case for "friend class" in C++?
>
>> 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.
>>
>
> This may be a valid reason for not adding 'any' new feature, but it is not a valid reason for not adding 'this' feature.
>

Isn't that a bit of a weak answer? Couldn't anybody proposing
a feature they want answer the same way?

>
>> 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.
>
> Putting one class in a module by itself, means no other code except that class is in that module, and therefore the class does not need to 'hide' anything from any other code in the module - cause there isn't any other code in the module.
>
> But putting one class in a module by itself, demonstrates no intent whatsoever.
>
> You have to ask the designer why they chose to do that.
>
> The option suggested would 'explicately' specify an intent, and can do so *without* enforcing a one-class-per-module design constraint onto the programmer.


If what you say were true, couldn't we say that from now on putting
a class alone in a module shows the intent of making private mean
private to the class?

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

If the object in the same module is visible, why make it private when you're already writing code? You are already partially isolating using underscore (Foo._id). For example, Foo.length will never conflict.

What difference would it make to see or not see this error?

> Error: no property `id` for type `source.Foo`

On Tuesday, 14 June 2022 at 07:12:18 UTC, Salih Dincer wrote:
>
> If the object in the same module is visible, why make it private when you're already writing code? You are already partially isolating using underscore (Foo._id). For example, Foo.length will never conflict.
>
> What difference would it make to see or not see this error?
>
>> Error: no property `id` for type `source.Foo`

yes, 'private' in this case is pointless.

but the example, is the kind of code I, and many like me, will come to D and write, expecting that private means private to the scope of the class.

Since private means private to the scope of the module, how then do I (and those like me) specifiy that intent in D? That's the question that has prompted this idea of adding a scope private option.

Also, while some use the underscore convention to indicate something is scope private, it doesn't necessarily follow that anyone who used underscore was specifying that to be scope private.

So isolating using an underscore doesn't really indicate intent, unless that was the intent, and it also depends on other considerations (e.g you teams coding style, etc).

I'm talking about an option that explicitely, unmistakingly, shows intent, and furthermore, an intent the compiler recognises and enforces at compile time.

private(scope) <- the intent cannot my inferred here, it is explicit.

_var <- does that underscore infer an intent for scope private?? You need additional information to make that judgement.

An underscore 'convention' is no substitute to an explicit intent that cannot be missinterpreted or mistakingly bypassed - the compiler will know my intent, and enforce it, and anyone reading/modifying/using my code will know my intent also.

the same conclusion must also apply to the one-class-per-module argument.

it's about knowing the intent, vs guessing what the intent was (or needing to obtain more information to understand the intent - e.g is it because our coding style say use an underscore to indicate this is scope private).

the compiler cannot infer why you used an underscore, nor can it infer why you put a class in a file by itself.

On Tuesday, 14 June 2022 at 07:34:43 UTC, forkit wrote:
> [...]
> _var <- does that underscore infer an intent for scope private?? You need additional information to make that judgement.
>
> An underscore 'convention' is no substitute to an explicit intent that cannot be missinterpreted or mistakingly bypassed - the compiler will know my intent, and enforce it, and anyone reading/modifying/using my code will know my intent also.
>
> the same conclusion must also apply to the one-class-per-module argument.
> [...]

You're right...

SDB@79

On Tuesday, 14 June 2022 at 05:43:49 UTC, forkit wrote:
>
> But the D programming language has no feature to declare such an intent. So where does this leave those programmers?

It leaves 99.9% of them going "Oh OK" and carrying on programming.


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

The argument is this... "If you have access to the source code of the module then you can already muck about with the internals of the class, you ought to know what you're doing so adding "strict private" doesn't actually gain you anything.


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

It eliminates 99% of the need for it. The other 1% is a gift to the gods of compromise in exchange for friend access between classes that need it.


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

If "People coming from Java expect X" was a good argument for adding X then D would just be Java.


> 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 onus is on you to demonstrate a genuine need for it other than it's just what people expect.

"but the example, is the kind of code I, and many like me, will come to D and write, expecting that private means private to the scope of the class."
That is a _you_ problem though. D ist different to other languages, you cannot except it to have all the features, or for features to behave the same way as other languages.

Now you can solve the 'problem' of not having _class private_ two ways already.
a) put the class in it's own module.
b) put the class decleration inside a function and use an interface declared at module scope.

In addition, _class private_ doesn't even solve the encapsulation 'problem' in the first place.
All member functions could still access all private class members. Consider the following:
```
class Foo {
class_private int _a;
void setA(int v) { _a = v < 42 ? v : 42; }
void oh_no() { _a = 666; /*fail!!*/ }
}
```

IMHO, _class private_ doesn't add any _value_ whatsoever, and it complicates metaprogramming.

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

The main cost is the opportunity cost [1]. Any effort we spend implementing, documenting, debugging, and teaching 'private(scope)' reduces the amount of effort we can spend on other things. Likewise, any effort new users learning D have to spend on learning 'private(scope)' reduces the amount of effort they can spend learning other parts of the language (or, for that matter, using D to solve their problems).

So the relevant questions here are:

1. Among all of the possible improvements we could make to D, is this particular one the *best* use of our limited resources, as a community?

2. Among all of the additional language features we could ask new users of D to learn, will this particular one give them the *most* benefit for their effort?

[1] https://en.wikipedia.org/wiki/Opportunity_cost