`restricted` member variables

[forkit]

On Wednesday, 22 June 2022 at 05:48:22 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 22 June 2022 at 00:32:59 UTC, forkit wrote:
>> The discussion as to whether its even worthwhile to allow 'an 
>> option' for members of a class to be private, is senseless. 
>> Every programmer should already know the benefit of having 
>> private class members.
>
> Yes, it is indeed true that class private ought to be the 
> default, but in the meanwhile you can use a convention like 
> prefixing with underscore.
>
> It is a bit ugly, but not more ugly than «scope private» or 
> «class private».

I don't argue that class default should be private.

I think most D programmers, would not appreciate this ;-)

I'd like it to be sure. I wish it was when D was designed.

But I'm not arguing for that now. A future version, maybe, if a 
majority decide that.

As far as defaults are concerned, valid arguments for both 
module-private and class-private can be presented. The Swift 
community also undertook discussions related to this, and they 
decided internal *was* the appropriate default for them. But 
Swift (rightly) allows programmers to have finer grained control 
over the class type (and others actually) including fileprivate, 
and private (like C++, C#.. god.. even Javascript now!).

But I am unaware of any argument, related to OOP and classes, 
where not having a language 'option' for declaring a member of a 
class as private, has provided a benefit to software engineering. 
I am fully aware of arguments in the other direction however ;-)

There is no such thing as a workaround here.

Any solution needs to ensure type safety, by (at least) having 
the compiler statically enforce it.

I'd love to get Bjarne Stroustrup, Anders Hejlsberg, Mads 
Torgersen, James Gosling and Chris Lattner, in a virtual meeting, 
and ask them this question:

"Do you think a class type should be able to declare members to 
be private?"
"Do you think such a declareation should be statically enforced 
by the compiler?"
"What do you think about the D Programming approach, of now 
giving the programmer that option?"

On the last question, I doubt I would get a response. Just a 
smirk from each of them ;-)