Synchronized classes have no public members

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Oct 13 00:17:18 PDT 2015


On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu 
wrote:
> https://github.com/D-Programming-Language/dmd/pull/5188 
> implements a rule defined in TDPL: synchronized classes shall 
> have no public members.
>
> The motivation behind this limitation is that member accesses 
> in synchronized objects should not occur without some handshake 
> occurring. Public members would make that possible and easy.
>
> Walter and I are on board with this change. However, it is a 
> breaking change so we want to gather a level of community 
> support before we push the button.

Well, as I understand it, technically, synchronized classes don't 
even exist in D at the moment - just synchronized functions (much 
as TDPL talks about D having synchronized classes and not 
synchronized functions). So, if that change only affects classes 
marked with synchronized and doesn't do anything to functions 
marked as synchronized, then the breakage is likely to be pretty 
small (pretty much just cases where someone didn't want to bother 
putting synchronized on every method individually). On the other 
hand, if it basically adds synchronized classes and disallows 
synchronized functions and actually moves us to what TDPL 
describes (or close to it), then it's basically going to break 
all uses of synchronized in classes aside from simply using 
synchronized blocks inside of a member function. If it's the 
latter, we definitely need an appropriate transition period.

Ultimately, I think that we're better off with TDPL's definition 
of synchronized classes than the synchronized functions that we 
have now, so I do think that the change should be made. However, 
I also think that synchronized classes as TDPL describes are 
limited enough to be of questionable usefulness. Stripping off 
the outer layer of shared is unlikely to be sufficient in all but 
basic cases (and synchronized classes can't do any better than 
that, I don't think), meaning that you're likely going to have to 
cast away shared to do much with shared anyway, in which case, 
having a synchronized class loses at least some of its value. It 
can still encapsulate shared (which is good), but it doesn't 
necessarily make it much easier or safer to use.

- Jonathan M Davis


More information about the Digitalmars-d mailing list