Adding a new design constraint to D

[Paul Backus]

On Tuesday, 14 June 2022 at 10:54:17 UTC, forkit wrote:
> On Tuesday, 14 June 2022 at 10:26:09 UTC, Paul Backus wrote:
>>
>> The main cost is the opportunity cost [1]. Any effort we spend 
>> implementing, documenting, debugging, and teaching 
>> 'private(scope)' reduces the amount of effort we can spend on 
>> other things. Likewise, any effort new users learning D have 
>> to spend on learning 'private(scope)' reduces the amount of 
>> effort they can spend learning other parts of the language 
>> (or, for that matter, using D to solve their problems).
>>
>
> you mean, like @mustuse ;-)
>
> a 'new' feature that I'll likely *never* have a need to use btw.

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.

In any case, if you want to write a DIP, please don't let me stop 
you. The people you have to convince are Walter and Atila, not me.