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 it's 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.
The solid part of the proposal is about disabling reads and
writes. The rest is pure convention: write structs instead of
functions, and somehow (???) benefit from a totally unsafe
implicit cast.
