On Tuesday, November 13, 2012 14:33:50 Andrei Alexandrescu wrote: > As long as a cast is required along the way, we can't claim victory. I > need to think about that scenario.
At this point, I don't see how it could be otherwise. Having the shared equivalent of const would just lead to that being used everywhere and defeat the purpose of shared in the first place. If it's not segregated, it's not doing its job. But that leaves us with most functions not working with shared, which is also a problem. Templates are a partial solution, but they obviously don't work for everything. In general, I would expect that all uses of shared would be protected by a mutex or synchronized block or other similar construct. It's just going to cause problems to do otherwise. There are some cases where if you can guarantee that writes and reads are atomic, you're fine skipping the mutexes, but those are relatively rare, particularly when you consider the issues in making anything but extremely trivial writes or reads atomic. That being the case, it doesn't really seem all that unreasonable to me for it to be normal to have to cast shared to non-shared to pass to functions as long as all of that code is protected with a mutex or another, similar construct - though if those functions aren't pure, you _could_ run into entertaining problems when a non-shared reference to the data gets wiled away somewhere in those function calls. But we seem to have contradictory requirements here of trying to segregate shared from normal, thread-local stuff but are still looking to be able to use shared with functions intended to be used with non-shared stuff. - Jonathan M Davis