shared - i need it to be useful

[Erik van Velzen]

On Thursday, 18 October 2018 at 20:07:54 UTC, Stanislav Blinov 
wrote:
> On Thursday, 18 October 2018 at 19:51:17 UTC, Erik van Velzen 
> wrote:
>> On Thursday, 18 October 2018 at 19:26:39 UTC, Stanislav Blinov
>
>>>> Manu said clearly that the receiving thread won't be able to 
>>>> read or write the pointer.
>>>
>>> Yes it will, by casting `shared` away. *Just like* his 
>>> proposed "wrap everything into" struct will. There's exactly 
>>> no difference.
>>>
>
>> Casting is inherently unsafe. Or at least, there's no 
>> threadsafe guarantee.
>
> So? That's the only way to implement required low-level access, 
> especially if we imagine that the part of Manu's proposal about 
> disabling reads and writes on `shared` values is a given. It's 
> the only way to implement Manu's Atomic!int, or at least 
> operation it requires, for example.
>
>>>> You can still disagree on the merits, but so far it has been 
>>>> demonstrated as a sound idea.
>>>
>>> No, it hasn't been.
>>
>> I think you are missing the wider point. I can write 
>> thread-unsafe code *right now*, no casts required. Just put 
>> shared at the declaration. The proposal would actually give 
>> some guarantees.
>
> No, I think you are missing the wider point. You can write 
> thread-unsafe code regardless of using `shared`, and regardless 
> of its implementation details. Allowing *implicit automatic 
> promotion* of *mutable thread-local* data to shared will allow 
> you to write even more thread-unsafe code, not less.

This may come as a surprise but I agree with this factually.

It's just that the extra guarantee provided by disallowing 
implicit casting to shared is not so valuable to me. If you have 
an object which can be used in both a thread-safe and a 
thread-unsafe way that's a bug or code smell. Like the earlier 
example with localInc() and sharedInc(). And we can't guarantee 
the safety of @trusted implementations anyways.

If the extra guarantee is not valuable, might as well allow it.

> The solid part of the proposal is about disabling reads and 
> writes. The rest is pure convention: write structs instead of 
> functions,

"Writing structs" seems acknowledging how it's usually done. And 
then you put these in a library with generic concurrent data 
structures.

> and somehow (???) benefit from a totally unsafe implicit cast.

(See first part)