My argument against this is just that these synchronization primitives
more or less go completely against the paradigm that std.concurrency
encourages. It just seems very awkward.
Andrei, do you have any input on this?
Regards,
Alex
On Tue, May 1, 2012 at 6:42 PM, Sean Kelly <
sean@invisibleduck.org
<mailto:
sean@invisibleduck.org>> wrote:
I think it was the suggestion that std.concurrency was to be the
only import necessary for all things related to concurrency.
core.thread was left out because spawn() was supposed to be used
instead. I'd be fine with making the imports private though.
On Apr 26, 2012, at 1:21 PM, Alex Rønne Petersen wrote:
> I just looked over the concurrency chapter and couldn't find any
mention of this.
>
> Regards,
> Alex
>
> On Thu, Apr 26, 2012 at 8:51 PM, Sean Kelly
<
sean@invisibleduck.org <mailto:
sean@invisibleduck.org>> wrote:
> On Apr 25, 2012, at 5:47 PM, Alex Rønne Petersen wrote:
>
> > Hi,
> >
> > I just noticed that std.concurrency public imports more or less
all of
> > the synchronization modules from druntime. This caused a whole
bunch
> > of name conflicts in my code. Is this really needed? The
average code
> > written with std.concurrency is not going to need *any* of these
> > primitives - I mean, that's the entire idea. In my case, I'm doing
> > very low-level hackery/abuse inside a garbage collector
> > implementation, so that doesn't really count as normal usage.
> >
> > I know it would be a breaking change, but could we please get
rid of
> > those public imports? I honestly doubt anyone's relying on
these, and
> > they're frankly a pain in the ass.
> >
> > (Also, the core.thread import is private, but these are public
- wat?)
>
>
> I think it's like this because TDPL stated it works this way.
I'd have to re-read the chapter to be sure though.
> ______________________________
_________________
> phobos mailing list