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