Shared - Another Thread

[Manu]

On Fri, Oct 19, 2018 at 5:05 PM Dominikus Dittes Scherkl via
Digitalmars-d <digitalmars-d at 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?