On Thursday, 18 October 2018 at 16:24:39 UTC, Manu wrote:
On Wednesday, 17 October 2018 at 22:56:26 UTC, H. S. Teoh wrote:
What cracks me up with Manu's proposal is that it is its
simplicity and lack of ambition that is criticized the most.
shared is a clusterfuck, according to what I gathered from the
forum, I never had yet to use it in my code. Manu's idea makes
it a little less of a clusterfuck, and people attack the idea
because it doesn't solve all and everything that's wrong with
shared. Funny.
Elaborate on this... It's clearly over-ambitious if anything.
What issues am I failing to address?
First of all, you called it "shared", but what your concept
describes is "theadsave".
If you had called it the later, it would have been clear to
everybody that thread local data is indeed automatically
threadsave, because only one thread has access to it (that
"implicit conversion"). But if something is "shared" (in the
common-world sense), it is of course no more "threadsave" - you
have to implement special methods to treat it.
Conflating "shared" and "threadsave" in that manner was, I think,
the biggest mistake of your proposal.
Another point is the part of "how can the compiler support the
expert in writing threadsave methods" - which you answered with
"not a little bit at the moment, but we may improve this in the
future" - and that is not at all satisfying. Are there really no
ideas? No check that the proper atomic funtions are used or the
cast to "unshared" is ok at where it is used? Even the expert
needs a little help to find the upcomming and well hidden bugs in
their oh so threadsave API...
