Synchronized classes have no public members

Sean Kelly via Digitalmars-d digitalmars-d at puremagic.com
Sat Oct 17 09:48:25 PDT 2015


On Friday, 16 October 2015 at 06:49:06 UTC, Dicebot wrote:
> On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg 
> wrote:
>> On 2015-10-15 16:28, Andrei Alexandrescu wrote:
>>
>>> That may be worrisome. Any information on how many are using 
>>> DWT, and
>>> how badly it would break if we pulled the change?
>>>
>>> If we assess there's too much breakage, we can define a DIP 
>>> and make the
>>> check opt-in via a flag -dipNN.
>>
>> I would like to add that the impact of a possible breakage 
>> depends on what the alternative is. If a function in Phobos or 
>> druntime is provided with the same functionality, then the 
>> breakage have less of an impact.
>
> As far as I understand topic is about deprecating direct field 
> access of synchronized classes, method calls in synhronized 
> classes and `synchronized () {}` blocks will remain untouched.

That clarifies things. It seems a fine idea. I can't think of an 
instance where it would be advisable to have public mutable 
fields in a synchronized class. Immutable or const though, sure.


More information about the Digitalmars-d mailing list