Why is D unpopular

[forkit]

On Monday, 13 June 2022 at 17:08:55 UTC, Ali Çehreli wrote:
>
> ...
> I was surprised too. Then I realized D's view was better that 
> C++'s (my frame of reference at the time). Then I realized I've 
> been under the influence of C++'s view of OOP. Then I thought 
> more about what encapsulation actually means. Then I realized 
> encapsulation has nothing to do with access control. I am much 
> happier with this repaired frame of reference.
>

Really? Sure, you can separate interface from implementation, 
without access control.

But you can also ensure you don't put signed int, into unsigned 
int - by 'just not doing it'.

It's the 'just don't do it' approach that bothers me.

The 'just don't do it' philosophy, of D, s not a good tool to 
rely on, in software design and development, especially at scale.

That is where 'private(scope)' comes in handy.

If I 'do' do it, or someone else 'does it', then the compiler 
will know that what I'm doing, or someone else is doing, 
conflicts with the intent as specified in the class.

It provides an level of assurance, that you simply cannot get 
without it.

That's its benefit.

There is no downside.

You always have the choice to use it or not - that should always 
be up to you to decide.

The problem with D, is that it decides this for you, and leaves 
you with only to options:

(1) just don't do it.
(2) put the class in its own file

To me, this is uncessarily restrictive, and puts an immediate 
constraint on me, before I've even begun to consider what design 
is best for me.



> > And the
> > 'friend' story rarely impresses them. The reply is always:
> "Ok, 'friend'
> > breaks OOP principles. Is D better because it breaks OOP in
> its own way?"
>

The 'friend' argument is a strawman.

No D programmer would need to alter anything they currently do, 
with the 'option' that I'm asking for.

But a large number of programmers coming to D, will have to 
change what they're currently doing - cause they have no option.


>
> I find D's 'private' very useful and I doubt a single project 
> had any problem with it.
>
> Ali

this is another strawman.

the problem is not the d module, it's not having a choice.