On Saturday, 20 October 2018 at 00:00:49 UTC, Dominikus Dittes Scherkl wrote:
> Hmm.
> mutable, immutable and const form a triple, the second is a declaration attribute, the last an parameter attribute, indicating that you don't want to modify the parameter, may it be because you can't (as it is immutable) or you only don't need to despite it would be possible (if it was mutable). The later is your responsibility to guarantee (with the help from the compiler).
> Therefore it is possible to implicitly cast from mutable or immutable to const but not in any other direction.
>
> I think for unshared, shared and threadsave it should be the same:
> The second is a declaration attribute, the third a parameter attribute. The first two can implicitly be cast to threadsave, may be because it is thread-local and therefore no race condition is possible, or may be because you take special care in your type to guarantee the thread safety by using atomic operations or locking or whatever.
> That make it possible, that the implicit cast from shared to unshared can be avoided while still providing functions that can take both kinds of arguments.
>
> Yes, that would add a little to the attribute bloat (new keyword) but not to the number of attributes per type or parameter.

Mutable = value may change
const = I will not change the value
immutable = the value will not change

unshared = I (well the current thread) owns the reference
shared = reference not owned, no unordered access, no (unordered) writes
threadsafe = ???

On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson wrote:
> Mutable = value may change
> const = I will not change the value
> immutable = the value will not change
>
> unshared = I (well the current thread) owns the reference
> shared = reference not owned, no unordered access, no (unordered) writes
> threadsafe = ???
unshared = the current thread owns the reference
threadsafe = I guarantee no race conditions or deadlocks will occur
shared = every thread may have references

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.

On Fri, Oct 19, 2018 at 5:05 PM Dominikus Dittes Scherkl via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> Therefore it is possible to implicitly cast from mutable or immutable to const but not in any other direction.
>
> I think for unshared, shared and threadsave it should be the same: The second is a declaration attribute, the third a parameter attribute.

I certainly had this thought... if you take a purist point of view, it
sounds reasonable.
BUT, I think it's a bad choice for practical reasons:
1. Adding a new attribute is heavy handed.
2. It's also unnecessary; the one that would be analogous to immutable
is not actually very interesting. At best, it offers the potential for
a small number of optimisations, which can be accessed without it.
3. Threadsafety carries a VERY small surface area in the language and
in code in general... we don't need to add a pile of machinery for
this.

Sure, immutable is kinda nice, but in strict terms, it's
unnecessary... we could all get on without it. If immutable were
removed from the language completely, it would barely affect me. We
couldn't get on without const.
The same applies here, we must have the const analogous one. Can't
live without that.

Consider the frequency of immutable to const in any code you've ever
seen. This is a very real view of the relative usefulness of the 2
constructs.
Now imagine the same comparison to shared... you hardly see shared at
all to begin with; and the one analogous to immutable would be
relatively so much more rare still.
How can you find that such a construct carries its weight with respect
to its rare-ness, when its usefulness is very limited to begin with?

On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote:
> How can you find that such a construct carries its weight with respect
> to its rare-ness, when its usefulness is very limited to begin with?

I suggested it only because of the resistance to the proposed implicit cast to shared. But I agree - a cast from mutable to immutable could also be implicit, and would rarely cause any problems. Still, I'm sure you would face equally strong resistance against that.

On Sat., 20 Oct. 2018, 12:10 am Dominikus Dittes Scherkl via Digitalmars-d, <digitalmars-d@puremagic.com> wrote:

> On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote:
> > How can you find that such a construct carries its weight with
> > respect
> > to its rare-ness, when its usefulness is very limited to begin
> > with?
>
> I suggested it only because of the resistance to the proposed implicit cast to shared. But I agree - a cast from mutable to immutable could also be implicit, and would rarely cause any problems. Still, I'm sure you would face equally strong resistance against that.
>

It is necessary. My dream of a @safe shared is immaterial without that
single important detail.
I can't make use of shared without it, at least, not safely, and then we
might as well all just pack up and go home.

>

On Sat., 20 Oct. 2018, 12:10 am Dominikus Dittes Scherkl via Digitalmars-d, <digitalmars-d@puremagic.com> wrote:

> On Saturday, 20 October 2018 at 06:04:45 UTC, Manu wrote:
> > How can you find that such a construct carries its weight with
> > respect
> > to its rare-ness, when its usefulness is very limited to begin
> > with?
>
> I suggested it only because of the resistance to the proposed implicit cast to shared. But I agree - a cast from mutable to immutable could also be implicit, and would rarely cause any problems. Still, I'm sure you would face equally strong resistance against that.
>

If an implicit cast from mutable to immutable existed, then immutable would just be const ;)

>

On Saturday, 20 October 2018 at 02:09:56 UTC, Dominikus Dittes Scherkl wrote:
> On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson wrote:
>> Mutable = value may change
>> const = I will not change the value
>> immutable = the value will not change
>>
>> unshared = I (well the current thread) owns the reference
>> shared = reference not owned, no unordered access, no (unordered) writes
>> threadsafe = ???
> unshared = the current thread owns the reference
> threadsafe = I guarantee no race conditions or deadlocks will occur
> shared = every thread may have references

Exactly, "thredsafe" in nothing more than a contract between programmers.
When you have "const" data, it is trivial for the compiler to enforce that: it just doesn't allow you to mutate it. But the compiler cannot reason about whether your logic is "threadsafe" or not, there can be no static enforcement of "thread-safety". It only holds as an implicit contract between programmers: the authors of data and functions, and the users of that data and functions, i.e. the API and the callers.

On Sat., 20 Oct. 2018, 7:00 am Stanislav Blinov via Digitalmars-d, < digitalmars-d@puremagic.com> wrote:

> On Saturday, 20 October 2018 at 02:09:56 UTC, Dominikus Dittes Scherkl wrote:
> > On Saturday, 20 October 2018 at 00:46:36 UTC, Nicholas Wilson wrote:
> >> Mutable = value may change
> >> const = I will not change the value
> >> immutable = the value will not change
> >>
> >> unshared = I (well the current thread) owns the reference
> >> shared = reference not owned, no unordered access, no
> >> (unordered) writes
> >> threadsafe = ???
> > unshared = the current thread owns the reference
> > threadsafe = I guarantee no race conditions or deadlocks will
> > occur
> > shared = every thread may have references
>
> Exactly, "thredsafe" in nothing more than a contract between
> programmers.
> When you have "const" data, it is trivial for the compiler to
> enforce that: it just doesn't allow you to mutate it. But the
> compiler cannot reason about whether your logic is "threadsafe"
> or not, there can be no static enforcement of "thread-safety". It
> only holds as an implicit contract between programmers: the
> authors of data and functions, and the users of that data and
> functions, i.e. the API and the callers.
>

Only at the level of the trusted functions.
It is *very* easy to write a correct Atomic implementation. Queues and
stuff are well understood and have great reference implementations. If you
don't write @trusted functions (most wouldn't!), then you can't mess up.

>