Okay, so I've been thinking on this for a while... I think I have a pretty good feel for how shared is meant to be.
1. shared should behave exactly like const, except in addition to inhibiting write access, it also inhibits read access. I think this is the foundation for a useful definition for shared, and it's REALLY easy to understand and explain. Current situation where you can arbitrarily access shared members undermines any value it has. Shared must assure you don't access members unsafely, and the only way to do that with respect to data members, is to inhibit access completely. I think shared is just const without read access. Assuming this world... how do you use shared? 1. traditional; assert that the object become thread-local by acquiring a lock, cast shared away 2. object may have shared methods; such methods CAN be called on shared instances. such methods may internally implement synchronisation to perform their function. perhaps methods of a lock-free queue structure for instance, or operator overloads on `Atomic!int`, etc. In practise, there is no functional change in usage from the current implementation, except we disallow unsafe accesses (which will make the thing useful). >From there, it opens up another critical opportunity; T* -> shared(T)* promotion. Const would be useless without T* -> const(T)* promotion. Shared suffers a similar problem. If you write a lock-free queue for instance, and all the methods are `shared` (ie, threadsafe), then under the current rules, you can't interact with the object when it's not shared, and that's fairly useless. Assuming the rules above: "can't read or write to members", and the understanding that `shared` methods are expected to have threadsafe implementations (because that's the whole point), what are the risks from allowing T* -> shared(T)* conversion? All the risks that I think have been identified previously assume that you can arbitrarily modify the data. That's insanity... assume we fix that... I think the promotion actually becomes safe now...? Destroy...
