Should core.sync.mutex.Mutex, core.sync.condition.Condition, etc. have all their methods be shared?

[Jonathan M Davis]

On Sunday, November 18, 2012 05:51:00 Alex Rønne Petersen wrote:
> On 18-11-2012 05:46, Jonathan M Davis wrote:
> > I don't know if we can answer this for sure at the moment given the
> > ongoing
> > discussion on shared, but looking at core.sync, it occurred to me that
> > there's a major problem with the classes in there. None of the work with
> > shared. And unless I'm missing something here, I don't see how many of
> > them are even useful as anything other than shared. After all, what good
> > is a mutex which is thread-local? But none of the methods on Mutex or its
> > friends are shared.
> > 
> > So, the question is should the all have their methods shared? And if they
> > should, is there any reason to have non-shared overloads for them? What
> > good are they as anything other than shared? How is anyone using them
> > right now?
> > 
> > - Jonathan M Davis
> 
> Not at this point in time. It would break a ridiculous amount of code if
> we did this, given the current extremely annoying nature of shared.
> 
> Most D code I have seen in the wild just shares mutexes, conditions, etc
> with __gshared or some other mechanism anyway, so I don't think there's
> anything to gain. Like, what would shared actually buy you here?

__gshared is a good reason for leaving non-shared overloads, but isn't code 
really supposed to be using shared and not __gshared unless it's specifically 
extern(C)? That being the case, I'd expect shared to be the correct thing to 
use with mutexes normally, and right now, that won't work without a ton of 
casting or adding shared overloads.

- Jonathan M Davis