Preparing for the New DIP Process

jmh530 john.michael.hall at gmail.com
Thu Jan 25 16:39:21 UTC 2024


On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
> On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis 
> wrote:
>
>>
>> Of course, ultimately, different programmers have different 
>> preferences, and none of us are going to be happy about 
>> everything in any language.
>
> It's not only about preferences. The feature is inconsistent 
> with how 'invariant' and 'synchronized' are specified. They 
> imply class-instance-level private, while the language dictates 
> module-level. Consider:
>
> ```
> synchronized class C
> {
>     private int x;
>     private int y;
>
>     invariant () { assert (x == y); }
> }
>
> void foo(C c)
> {
>     // mutate c
> }
> ```
>
> With module-level private, 'foo' is part of C's public 
> interface, but it neither locks on c, nor runs the invariant 
> checks. I personally have no idea how to fix that sensibly 
> except by ditching class invariant/synchronized entirely.

Is there issue with module-private, invariant, and synchronized 
solely the result of the interaction between all three? Or is 
there an issue with module-private and invariant by themselves 
(i.e. if C is not synchronized)?


More information about the Digitalmars-d-announce mailing list