On Fri, Oct 19, 2018 at 4:45 PM Dominikus Dittes Scherkl via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Friday, 19 October 2018 at 18:11:50 UTC, Manu wrote: > > On Fri, Oct 19, 2018 at 6:45 AM Dominikus Dittes Scherkl via > > Digitalmars-d <digitalmars-d@puremagic.com> wrote: > >> > >> On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote: > >> > [...] What issues am I failing to address? > >> [...] Another point is the part of "how can the compiler > >> support the expert in writing threadsave methods" - which you > >> answered with "not a little bit at the moment, but we may > >> improve this in the future" - and that is not at all > >> satisfying. > > > > I think you've misunderstood. > > My proposal is @safe... if you stay @safe, you will receive > > guarantee that your code is threadsafe. > On user side, yes. > > If you want to implement a low-level device, you must implement > > a @trusted function, and I don't know what the compiler can do > > to help you. > Yes, but that's seldom. More often the "expert" will write new > shared types using the low level trusted functions like anybody > else. But that > still requires special care - he has to consider tread-safety in > every > method of a new type, even the non-shared ones. And he has to > fill any > possible gap like construction and assignment so that the > end-user is really sure to not accidentally misusing the type! > And I think a serious proposal need to address this - I think the > compiler could really help here (e.g. prescribe what operators > need to be overloaded and check that all methods use the proper > mechanisms to lock the shared members before operating on them > etc.) > > > So saying that my response that "there is @trusted code at the > > bottom of the stack" is not satisfying is really just a comment > > on your opinion about @trusted code in general. > That just comes on top of it. > > > My proposal is designed to be useful and @safe for *users* as > > primary goal. > I agree with you, but others seem not so convinced (yet?). > [...] > > The user has manually cast to unshared inside their > > unsafe/(@trusted?) function, what more signal do they need that > > they've engaged in an unsafe operation? > Some hints what to do to be able to trust them? > You asked what issues you were failing to address. That was just > some ideas of mine what you may address in addition.
I understand. I don't have good ideas to add mechanical guarantees, other than something extremely likely to flag false-positives like "any `shared` piece of data involved in an unsafe cast in any function should look suspicious when accessed elsewhere within this module"...? I think this is an area for further development, but I don't think it's a barrier to making shared a useful @safe language construct with respect to the type safety. It is possible to define the typesafety rules correctly and then start writing experimental code. > More often the "expert" will write new > shared types using the low level trusted functions like anybody > else. But that > still requires special care - he has to consider tread-safety in > every > method of a new type, even the non-shared ones. This shouldn't be true unless they're writing new @trusted functions. If they're staying @safe, then there is nothing you can do to the lower-level utility that's not threadsafe, so you can freely use it throughout your new type. If this is true, then the @trusted function is not threadsafe as it promises. One thing I know is, your proposition above is unusual. In my experience among hundreds, perhaps thousands of colleagues, people don't just start presuming to write threadsafe tooling. We have 4-5 such threadsafe tools in our library, they are at the bottom of the stack, and would contain @trusted functions under my proposal... all other code just makes use of them (and quite extensive use of them!). People don't write new thredsafe machinery for fun, it's a very serious endeavour. The countless uses of those tools and the structure built on top should be @safely interactible, which is possible under my proposal.
