`restricted` member variables

[forkit]

On Tuesday, 21 June 2022 at 23:59:03 UTC, deadalnix wrote:
>
> Considering you failed to point at any concrete problem caused 
> by that design decision, I'll now have to increase my 
> confidence in the fact that there is none.
>
> After, if there were, you'd have stated them.

Well i had a thread where all these things could have been 
discussed ;-)

One of the 'biggest' selling points of D (certainly for me), was 
it's syntax being compatible with the syntax of the languages 
whose developers D was targetting. That was a good decision, and 
has really paid off, no doubt about it.

But as to why Walter then decided to completely change the 
concept of class, for those same programmers, has, and always 
will be, a pain point for D  - and that continues to be 
self-evident, from at least 2004.

It's much easier to learn new syntax, than changing (and 
especially being forced to change), a concept that has been the 
same...for decades...

To me, members of a class should be private by default, but you 
should have the option to make some public (and indeed, you need 
that option). I'd anticipate that *most* programmers would agree.

But the idea that member of a class must be ALWAYS public, is 
just crazy nonsense! That's not a class type, that's a 
'doWhatEverTheFu%$YouWantWithMe' type.

If you don't get that, you should not be programming.

As Walter has pointed out himself, the one-class-per-module is an 
unreasonable constraint to impose on a developer.

https://forum.dlang.org/post/pr110b$9j5$1@digitalmars.com

The only discussion worth having about this, is the technical 
aspects and consequences of implementing such an option (i.e. 
should it be soft-private or hard-private, for example.).

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.