`restricted` member variables

[forkit]

On Wednesday, 22 June 2022 at 22:47:11 UTC, max haughton wrote:
> On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
>> On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:
>>> On Wednesday, 22 June 2022 at 08:01:12 UTC, forkit wrote:
>>>> [...]
>>>
>>> Here you go: https://github.com/dlang/dmd/pull/14238
>>
>> +1
>>
>> ballsy ;-)
>>
>> maxhaton's comment is interesting "I don't think I've ever 
>> actually seen a bug that would've been fixed by this."
>>
>> I refer maxhaton back to the seminal paper on the benefits of 
>> abstract data types:
>>
>> Programming with abstract data types - Liskov and Zilles 1974
>>
>> https://dl.acm.org/doi/pdf/10.1145/942572.807045
>
> To which I ask again: Real example?

I don't get it.

You want evidence that abstract data types (types as defined by 
Liskov and Zilles) contribute to better program modularity? Isn't 
that self evident?

Isn't it also self-evident, that greater modularity leads to 
programs that can be better understood, modified, maintained, and 
proved correct?

You really need a 'real example' for this?

D requires you to think of the D module as being the overarching 
abstract data type. This results in the kind of design we 
typically see in D programming.

private(this) enables, and encourages, greater module-level 
modularity, enabling programmers to think more carefully about 
abstractions within the module itself.

private(this) enables the type protection that Liskov and Zilles 
talk about.

Without type protection, you're left with an immutable string 
that's only immutable as long as those using it (including the 
programmer), don't try to mutate it.

C'mon. I mean really. Are you seriously making an argument, that 
no benefit can come from 'private(this)'?