On Sun, Oct 7, 2018 at 10:00 AM Boris-Barboris via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On Sunday, 7 October 2018 at 02:01:17 UTC, Manu wrote: > > ... but I'm really struggling > > to express it in terms of the type system... > > I'm pretty sure no simple attribute system is any more useful > than current const\shared idiom. I am yet to see a language with > semantics that actually help with concurrency issues > (serializability, lock domains, lock ordering, deadlock > prevention\detection, consistency, write scew and hundreds of > other problems already known in the domain) on mutable state. SQL > didn't solve it, I still always have to grab pen and paper and > brute-force simulate concurrent access to my data in order to > have any degree of prior knowledge about safety, and > unfortunately this problem does not look like an easy one to > crack for language designers. > > This is why I mainly ignore shared as a feature completely unless > I'm forced to. A simple indication (type system attribute) of the > fact that data is shared is useless for my recent projects just > adds unneeded casts and lines of code without solving any > problems.
In our ecosystem within the structure of our scheduling, we would absolutely get loads of use out of shared if it was unable to access non-shared members. That's a major step forward in usefulness compared to now, where you can just read/write to members arbitrarily, which is just plain wrong, and not useful in any way. If shared inhibited access to non-shared members, thereby requiring you interface the instance only via shared attributed methods (or the traditional acquire-lock-and-cast-shared-away method), then it would be infinitely more useful than it is now. If anyone wanted to make an experimental patch with that rule, I could test-drive and see how it goes. Point is, shared is totally useless. Making it useful, even if it's not 100% solving threading issues, is a better place to be, and opens up doors for some new designs, and get more experience.
