On Sun, Sep 30, 2018 at 9:00 PM Nicholas Wilson via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
>
> On Monday, 1 October 2018 at 03:33:16 UTC, Manu wrote:
> > On Sun, Sep 30, 2018 at 8:20 PM Nicholas Wilson via
> > Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On Monday, 1 October 2018 at 02:29:40 UTC, Manu wrote:
> >> > struct Bob
> >> > {
> >> > void setThing() shared;
> >> > }
> >> >
> >> > As I understand, `shared` attribution intends to guarantee
> >> > that
> >> > I dun
> >> > synchronisation internally.
> >> > This method is declared shared, so if I have shared
> >> > instances,
> >> > I can
> >> > call it... because it must handle thread-safety internally.
> >>
> >> seems reasonable
> >>
> >> https://github.com/dlang/dmd/pull/8782
> >
> > Haha, sneaky bugger :P
> > I reckon the patch is gonna be a lot bigger than that though!
>
> Of course, there will be updating the test suite. And Walter will
> probably tell you to bugzilla this.
>
> implicit conversion of mutable (i.e. no mods) to const share
> should be absolutely no problem, as that it rusts borrowing model
> (one owning mutable thread local reference and zero or more non
> thread local non-owning const references) and is fine.
>
> mutable to mutable shared I'm not so sure as references to
> otherwise owned references could escape.
>
> shared Bob* sneaky;
>
> struct Bob
> {
> void setSneaky() shared // legit as this is shared
> {
> sneaky = &this;
> }
> }
> void oblivious(ref shared Bob a, ref Bob b)
> {
> a.setSneaky(); // Fine
>
> b. setSneaky(); // would become not an error, but totally not
> fine.
> }
>
> unfortunately scope is not a modifier so the PR will have to be
> larger, oh well.
Ah, good point. So, it could only be allowed if scope...
struct Bob
{
void setThing() shared scope;
}
That's going to require far-reaching proliferation of `scope`.
Do we infer `scope` like the other attributes? The default for `scope`
is totally backwards. :/
