Why is D unpopular

[Mike Parker]

On Monday, 13 June 2022 at 02:42:52 UTC, forkit wrote:

> Withing a module:
>
> (1) What is the disadvantage of having an 'optional' access 
> modifier, such as 'class private', so that you can separate 
> interface from implementation?
>
> (2) what is the disadvantage in leveraging the compiler to help 
> us in determining whether code outside that class, but within 
> the same module, is correctly using that interface?

That's backwards. You're talking about adding a new language 
feature. The bar in that case is to show that the new feature 
provides an advantage over the status quo, such that the 
additional complexity is justified.

That's what this boils down to. Walter and Atila are who you need 
to convince. Not me.

I just don't see *practical* advantage to it. Let's say I have 
this class using a shiny new `private(intern)` feature 
implemented by someone on my team.


```d
class Foo {
    private(intern) x;
}
```

Now I want to add a function in the module that manipulates `x`.

```d
void newFunction(Foo f) {
     f.x = 10;
}
```

Oops! Can't do that. But no problem. I have access to the source. 
I can change `x` to `private` so that I can access it everywhere 
in the module. Or I add a new `private(intern)` member function 
to set the value of `x` in the way I need it.

This is the reason I think it's a useless feature. If you have 
access to the module, you have access to the internal members of 
the class. It's no different than having a class per file in 
Java. At some point, it comes down to coding conventions (e.g., 
all internal access to private members within a Java class must 
explicitly go through the public interface).

How does this feature bring any benefit that can't be had by 
putting `Foo` in a separate module? That's the question you have 
to answer.