Adding a new design constraint to D

[forkit]

On Tuesday, 14 June 2022 at 11:22:58 UTC, Paul Backus wrote:
>
> ...
> Sure, you could make an argument that the effort spent on 
> @mustuse could have been better spent elsewhere.
>
> The main difference between @mustuse and private(scope) is that 
> @mustuse was *impossible* to simulate using existing language 
> features, whereas private(scope) can be simulated by extracting 
> the relevant code into its own dedicated module. I understand 
> that you have reasons for disliking this workaround, but the 
> fact that a workaround exists is still relevant when 
> determining what ought to be prioritized.
>

I don't accept this argument either, because to 'simulate' 
private(scope) using the one-class-per-file approach, you must be 
willing to accept a considerable design constraint - i.e. 
one-class-per-module.

The cost of simulating, is too high. that is my point here.

It's not about disliking the workaround suggestion. It's about 
the cost of doing it.

Also, it's not actually simulating private(scope) anyway, not by 
any stretch of the imagination, since there is no other code 
besides the class, in that file.

It's just a workaround to avoid the need for private(scope), but 
at a considerable cost to the design choice you're then forced to 
accept in return.

To take a qoute of the internet:

"Having 17k line classes can be confusing, 17k line files with 
170 classes in it can be confusing, having 170 classes in 170 
files can be confusing.".