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)
