Adding a new design constraint to D

[forkit]

On Wednesday, 15 June 2022 at 02:15:16 UTC, norm wrote:
> On Wednesday, 15 June 2022 at 01:57:28 UTC, zjh wrote:
>> On Wednesday, 15 June 2022 at 01:21:51 UTC, monkyyy wrote:
>>
>>> Id suggest fixing ancient template bugs and getting several 
>>> competing compilers going to compete with c++;
>>
>> In any case, we should not be afraid of `change`! not be 
>> afraid of `complexity`!
>> Take a look at `'rust'`. It is becoming more and more 
>> `complex`. Take a look at `other mainstream languages`. Which 
>> is not `complex`?
>>
>> `C++23, c++26` is absolutely monsters! But people don't care!
>
> I find C++ is getting easier to use with each release. Bring on 
> C++23,26,... because each release adds new features that make 
> using C++ that much easier use correctly and harder to use 
> incorrectly.
>
> D's only real problem is people power. That will not be fixed 
> by the constant bickering seen on these forums, it just drives 
> potential developers away if anything. I said it before, 
> instead of worrying about private, which TBH is a tiny issue 
> because what is there now works reliably and well for 99% of 
> code, maybe help D progress with actions not words.
>

That's cause D still very much operates in the small (in more 
than one way).

languages that have this feature, operate in the large.

when you operate in the large, tighter encapsulation, explicit 
intent, enforceable design, become very important aspects in 
developing correct code.

when you operate in the small, these matter a lot less - and so 
they'll be seen as unnecssary, constraining, and unwelcome, and 
often result in bickering, as you say.

A lot of this controversy comes back to Walters firm view, that 
'the module' is the unit of encapsulation in D, 'and that's all 
there is too it' attitude.

Of course, anyone from OOP will know that a class is a very 
important unit of encapsulation in its own right.

What Walter fails to acknowledge in this 'firm view' (apart from 
the above), is that encapsulation is actually an abstract concept 
that can apply at any level whatsoever, including at the level of 
module-level-components (code inside a module).

Indeed most code within a module is already encapsulated in some 
way (by the code itself, not the module).

A function is encapsulated.

An enum is encapsulated.

Even an int is encapsulated.

A class is encapsulated .. well... actually, no.. it isn't. No in 
D. You can't do it.