On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 21.10.18 20:46, Manu wrote:
> >> Shared data is only useful if, at some point, it is read/written, presumably by casting it to unshared in @trusted code. As soon as that is done, you've got a data race with the other existing unshared aliases.
> > If such a race is possible, then the @trusted function is not
> > threadsafe, so it is not @trusted by definition.
> > You wrote a bad @trusted function, and you should feel bad.
> > ...
>
> I wonder where this "each piece of code is maintained by only one person and furthermore this is the only person that will suffer if the code has bugs" mentality comes from. It is very popular as well as obviously nonsense.
>
> > The simplest way to guarantee that no unsafe access is possible is to use encapsulation to assure no unregulated access exists.
>
> This only works if untrusted programmers (i.e. programmers who are only allowed to write/modify @safe code) are not allowed to change your class. I.e. it does not work.

Have you ever cracked open std::map and 'fixed' it because you thought
it was bad?
Of course not. Same applies here. Nobody 'fixes' core.atomic.Atomic
without understanding what they're doing.

You seem to be stuck on the detail whether you can trust the @trusted author though... that is a reasonable point of debate, but it's a slightly separate topic. I am confident that the number of @trusted functions required to found a useful stack are low, probably countable with fingers, and always in a library.

If we can put aside that point of debate just for now; whether you
feel the @trusted author can be trusted, assuming that they can, does
the model work? Can you break the model as I have presented it?
If not; if the model is sound, then we can begin the discussion you're
alluding to and talk about opportunities to improve on static
guarantees for @trusted authors, or ways to communicate their
responsibility clearly, and patterns to assure success.

On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
> On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
>> On 10/21/2018 2:08 PM, Walter Bright wrote:
>>> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
>>>> Yes, but the problem you describe is arises from implicit conversion in the other direction, which is not part of the proposal.
>>>
>>> It's Manu's example.
>>
>> Then I don't know what the proposal is. Pieces of it appear to be scattered over numerous posts, mixed in with other text, opinions, and handwavy stuff. There's nothing to point to that is "the proposal".
> 
> The proposal is:
> 
> Implicit conversion _to_ shared, e.g. passing it to a thread entry point, and not implicit conversion _from_ shared (just like implicit const conversions).

That's what I was referring to, and Manu's example. It doesn't work, as I pointed out.


>> I suggest you and Manu write up a proper proposal. Something that is complete, has nothing else in it, has a rationale, illuminating examples, and explains why alternatives are inferior.
> 
> We will eventually. This started as a "please point out any problems with this" and has probably outlived that phase.

You'll need to address the issues raised here in the DIP.

On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
> I just did,

Link please?

On Monday, 22 October 2018 at 00:46:04 UTC, Walter Bright wrote:
> That's what I was referring to, and Manu's example. It doesn't work, as I pointed out.

I'm pretty sure it does, but please repeat it.

>> We will eventually. This started as a "please point out any problems with this" and has probably outlived that phase.
>
> You'll need to address the issues raised here in the DIP.

That is a given. You would do well to heed it for your own DIPs.

On 22.10.18 02:45, Manu wrote:
> On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On 21.10.18 20:46, Manu wrote:
>>>> Shared data is only useful if, at some point, it is read/written, presumably by
>>>> casting it to unshared in @trusted code. As soon as that is done, you've got a
>>>> data race with the other existing unshared aliases.
>>> If such a race is possible, then the @trusted function is not
>>> threadsafe, so it is not @trusted by definition.
>>> You wrote a bad @trusted function, and you should feel bad.
>>> ...
>>
>> I wonder where this "each piece of code is maintained by only one person
>> and furthermore this is the only person that will suffer if the code has
>> bugs" mentality comes from. It is very popular as well as obviously
>> nonsense.
>>
>>> The simplest way to guarantee that no unsafe access is possible is to
>>> use encapsulation to assure no unregulated access exists.
>>
>> This only works if untrusted programmers (i.e. programmers who are only
>> allowed to write/modify @safe code) are not allowed to change your
>> class. I.e. it does not work.
> 
> Have you ever cracked open std::map and 'fixed' it because you thought
> it was bad?
> Of course not. Same applies here. Nobody 'fixes' core.atomic.Atomic
> without understanding what they're doing.
> 

You are not proposing to let core.atomic.Atomic convert to shared implicitly, you are proposing to do that for all classes.

> You seem to be stuck on the detail whether you can trust the @trusted
> author though...

Again: the @safe author is the problem.

On Sun, Oct 21, 2018 at 5:50 PM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
> > On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
> >> On 10/21/2018 2:08 PM, Walter Bright wrote:
> >>> On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
> >>>> Yes, but the problem you describe is arises from implicit conversion in the other direction, which is not part of the proposal.
> >>>
> >>> It's Manu's example.
> >>
> >> Then I don't know what the proposal is. Pieces of it appear to be scattered over numerous posts, mixed in with other text, opinions, and handwavy stuff. There's nothing to point to that is "the proposal".
> >
> > The proposal is:
> >
> > Implicit conversion _to_ shared, e.g. passing it to a thread entry point, and not implicit conversion _from_ shared (just like implicit const conversions).
>
> That's what I was referring to, and Manu's example. It doesn't work, as I pointed out.
>
>
> >> I suggest you and Manu write up a proper proposal. Something that is complete, has nothing else in it, has a rationale, illuminating examples, and explains why alternatives are inferior.
> >
> > We will eventually. This started as a "please point out any problems with this" and has probably outlived that phase.
>
> You'll need to address the issues raised here in the DIP.

Would you please respond to my messages, and specifically, respond to
the code that I presented to you in response to your broken example.
Or any of my earlier fragments throughout this thread. I've shared
quite a few, and so far, nobody has ever produced a criticism of any
of my fragments. They've just been skipped over.
But the one aimed directly at your own most recent sample program
addresses your program directly.

On Sun, Oct 21, 2018 at 5:40 PM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 21.10.18 21:04, Manu wrote:
> > On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 21.10.18 17:54, Nicholas Wilson wrote:
> >>>
> >>>> As soon as that is done, you've got a data race with the other existing unshared aliases.
> >>>
> >>> You're in @trusted code, that is the whole point. The onus is on the programmer to make that correct, same with regular @safe/@trusted@system code.
> >>
> >> Not all of the parties that participate in the data race are in @trusted code. The point of @trusted is modularity: you manually check @trusted code according to some set of restrictions and then you are sure that there is no memory corruption.
> >>
> >> Note that you are not allowed to look at any of the @safe code while checking your @trusted code. You will only see an opaque interface to the @safe code that you call and all you know is that all the @safe code type checks according to @safe rules. Note that there might be an arbitrary number of @safe functions and methods that you do not see.
> >>
> >> Think about it this way: you first write all the @trusted and @system code, and some evil guy who does not like you comes in after you looks at your code and writes all the @safe code. If there is any memory corruption, it will be your fault and you will face harsh consequences. Now, design the @safe type checking rules. It won't be MP!
> >>
> >> Note that there may well be a good way to get the good properties of MP without breaking the type system, but MP itself is not good because it breaks @safe.
> >
> > Show me. Nobody has been able to show that yet. I'd really like to know this.
> >
>
> I just did,

There's no code there... just a presumption that the person who wrote the @trusted code did not deliver the promise they made.

> but if you really need to, give me a non-trivial piece of> correct multithreaded code that accesses some declared-unshared field
> from a shared method and I will show you how the evil guy would modify
> some @safe code in it and introduce race conditions. It needs to be your
> code, as otherwise you will just claim again that it is me who wrote bad
> @trusted code.

You can pick on any of my prior code fragments. They've all been ignored so far.

On 22.10.18 02:46, Nicholas Wilson wrote:
> On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
>> I just did,
> 
> Link please?
> 

https://forum.dlang.org/post/pqii8k$11u3$1@digitalmars.com

On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On 22.10.18 02:45, Manu wrote:
> > On Sun, Oct 21, 2018 at 5:35 PM Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>
> >> On 21.10.18 20:46, Manu wrote:
> >>>> Shared data is only useful if, at some point, it is read/written, presumably by casting it to unshared in @trusted code. As soon as that is done, you've got a data race with the other existing unshared aliases.
> >>> If such a race is possible, then the @trusted function is not
> >>> threadsafe, so it is not @trusted by definition.
> >>> You wrote a bad @trusted function, and you should feel bad.
> >>> ...
> >>
> >> I wonder where this "each piece of code is maintained by only one person and furthermore this is the only person that will suffer if the code has bugs" mentality comes from. It is very popular as well as obviously nonsense.
> >>
> >>> The simplest way to guarantee that no unsafe access is possible is to use encapsulation to assure no unregulated access exists.
> >>
> >> This only works if untrusted programmers (i.e. programmers who are only allowed to write/modify @safe code) are not allowed to change your class. I.e. it does not work.
> >
> > Have you ever cracked open std::map and 'fixed' it because you thought
> > it was bad?
> > Of course not. Same applies here. Nobody 'fixes' core.atomic.Atomic
> > without understanding what they're doing.
> >
>
> You are not proposing to let core.atomic.Atomic convert to shared implicitly, you are proposing to do that for all classes.

You can always implicitly convert to shared.
Where did I ever say anything like that? I'm sure I've never said
this. How do these transformations of what I've said keep happening?

> > You seem to be stuck on the detail whether you can trust the @trusted author though...
>
> Again: the @safe author is the problem.

I don't follow. The @safe author is incapable of doing threadsafety
violation. They can only combine threadsafe functions.
They can certainly produce a program that doesn't work, and they are
capable of ordering issues, but that's not the same as data-race
related crash bugs.

On Monday, 22 October 2018 at 00:55:00 UTC, Timon Gehr wrote:
> On 22.10.18 02:46, Nicholas Wilson wrote:
>> On Monday, 22 October 2018 at 00:38:33 UTC, Timon Gehr wrote:
>>> I just did,
>> 
>> Link please?
>> 
>
> https://forum.dlang.org/post/pqii8k$11u3$1@digitalmars.com

That contains no code.

>Not all of the parties that participate in the data race are in @trusted code.

There are two cases of @trusted code, bad and good. Bad trusted code can indeed be misused by @safe code to corrupt memory. Good trusted code cannot.

What part of the proposal breaks the type system? The implicit conversion to shared implies that the passed to function is @safe iff all the functions it calls are @safe only call function with that parameter to other shared @safe functions _OR_ they are @trusted.

> The point of @trusted is modularity: you manually check @trusted code according to some set of restrictions and then you are sure that there is no memory corruption.

Yes. And?