Why is D unpopular

[forkit]

On Monday, 13 June 2022 at 03:46:52 UTC, Mike Parker wrote:
> 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.

In your example, there is no benefit. There is only a couple of 
lines of code in the module. I can chunk the whole module almost 
in one go.

That approach is not scalable because: first, humans decipher 
information using chunks, and second, humans make mistakes.

The argument that you have access to the source file is a 
strawman.

The one-class-per-file is also a strawman.

Why not one struct per file, one enum per file, one function per 
file, one int per file ... why only a class-per-file?

This is not about this approach or that approach.

It's about giving the programmer an option to decide which 
approach is best for them.

Your side of the argument is basically saying we don't want to 
give you that option - cause we know what approach is best for 
you.