Generality creep

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Apr 1 10:03:13 UTC 2019


On Sunday, March 31, 2019 4:25:30 PM MDT Manu via Digitalmars-d wrote:
> On Sat, Mar 30, 2019 at 5:45 PM Andrei Alexandrescu via Digitalmars-d
>
> <digitalmars-d at puremagic.com> wrote:
> > On 3/30/19 2:49 PM, Jonathan M Davis wrote:
> > > This would also be a great opportunity to fix some of the issues with
> > > shared in druntime
> >
> > The problem here is, of course, that nobody knows exactly what shared is
> > supposed to do. Not even me. Not even Walter.
>
> As an immediate stop-gap, shared must have *no read or write access*
> to data members. Simple. Make that change. Right now.
> Then shared will at least be useful and not embarrassing, and you can
> continue to argue about what shared means while I get to work.
>
> > One monumental piece of work would be DIP 1021 "Define the semantics of
> > shared". Then people who build with -dip1021 know what to do and what to
> > expect. Now that would patch one of the bigger holes mentioned in the
> > other post.
>
> Sure. But in the meantime, fix the objective bug with the current
> semantics where you can read/write un-protected data freely. Right
> now. Please for the love of god.

Honestly, that's really what shared is missing. _Some_ operations which
aren't guaranteed to be thread-safe are illegal, but many aren't. With that
fixed, I don't know what else shared would actually need. The stuff in
core.sync really needs to be fixed up to use shared correctly (which is
critical for being able to use shared cleanly), but at that point, shared
itself would be doing what it needs to be doing. We could then potentially
add stuff like synchronized classes on top of that, but that's just making
shared easier to use, not actually required for shared to work.

- Jonathan M Davis





More information about the Digitalmars-d mailing list