On Sun, Oct 21, 2018 at 3:00 AM Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 10/20/2018 11:08 AM, Nicholas Wilson wrote: > > You can if no-one else writes to it, which is the whole point of Manu's > > proposal. Perhaps it should be const shared instead of shared but still. > > There is no purpose whatsoever to data that can be neither read nor written.
There is no primitive type with implicit threadsafety... nor need there be. Shared data simply can not be read or written in any threadsafe manner. This is a rock-solid reality, and the type system needs to reflect that reality as a fundamental premise. Only from there can we start to define meaningful threadsafety. All threadsafe interactions with anything involve calling functions. It's completely reasonable to make `shared` inhibit all read and write access to data. We can only call shared methods, because only real-code can implement threadsafety. > Shared data is only useful if, at some point, it is read/written, presumably > by > casting it to unshared in @trusted code. As soon as that is done, you've got a > data race with the other existing unshared aliases. If such a race is possible, then the @trusted function is not threadsafe, so it is not @trusted by definition. You wrote a bad @trusted function, and you should feel bad. The simplest way to guarantee that no unsafe access is possible is to use encapsulation to assure no unregulated access exists.
