On 18.10.18 23:34, Erik van Velzen wrote:
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.
Then why do you not just make all members shared? Because with Manu's proposal, as soon as you have a shared method, all members effectively become shared. It just seems pointless to type them as unshared anyway and then rely on convention within @safe code to prevent unsafe accesses. Because, why? It just makes no sense.
With the proposal I posted in the beginning, you would then not only get implicit conversion of class references to shared, but also back to unshared.
I think the conflation of shared member functions and thread safe member functions is confusing. shared on a member function just means that the `this` reference is shared. The only use case for this is overloading on shared. The D approach to multithreading is that /all/ functions should be thread safe, but it is easier for some of them because they don't even need to access any shared state. It is therefore helpful if the type system cleanly separates shared from unshared state.
