shared - i need it to be useful

[Timon Gehr]

On 22.10.18 03:01, Manu wrote:
> On Sun, Oct 21, 2018 at 5:55 PM Timon Gehr via Digitalmars-d
> <digitalmars-d at 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 at 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?

(Also, yes, some people do that because std::map does not provide an 
interface to augment the binary search tree.)

>>> 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.

Yes, exactly what I said.

> Where did I ever say anything like that? I'm sure I've never said
> this.

???

I said that you are proposing to allow implicit conversions to shared 
for all classes, not only core.atomic.Atomic, and the last time you said 
it was the previous sentence of the same post.

> How do these transformations of what I've said keep happening?
> ...

You literally said that nobody changes core.atomic.Atomic. Anyway, even 
if I bought that @safe somehow should not be checked within druntime (I 
don't), bringing up this example does not make for a coherent argument 
why implicit conversion to shared should be allowed 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.
> 
> I don't follow. The @safe author is incapable of doing threadsafety
> violation.

They are capable of doing so as soon as you provide them a @trusted 
function that treats data as shared that they can access as unshared.

> 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.
> 

Accessing private members of aggregates in the same module is @safe. 
tupleof is @safe too.