On 10/17/18 10:18 AM, Timon Gehr wrote:
On 17.10.2018 15:40, Steven Schveighoffer wrote:
On 10/17/18 8:02 AM, Timon Gehr wrote:
Now, if a class has only shared members, that is another story. In
this case, all references should implicitly convert to shared.
There's a DIP I meant to write about this. (For all qualifiers, not
just shared).
When you say "shared members", you mean all the data is shared too or
just the methods are shared?
If not the data, D has a problem with encapsulation. Not only all the
methods on the class must be shared, but ALL code in the entire module
must be marked as using a shared class instance. Otherwise, other
functions could modify the private data without using the proper synch
mechanisms.
We are better off requiring the cast, or enforcing that one must use a
shared object to begin with.
I think any sometimes-shared object is in any case going to benefit
from parallel implementations for when the thing is unshared.
-Steve
The specific proposal was that, for example, if a class is defined like
this:
shared class C{
// ...
}
then shared(C) and C are implicitly convertible to each other. The
change is not fully backwards-compatible, because right now, this
annotation just makes all members (data and methods) shared, but child
classes may introduce unshared members.
OK, so the proposal is that all data and function members are shared.
That makes sense.
In one sense, because the class reference is conflated with the type
modifier, having a C that isn't shared, actually have it's class data be
shared, would be useful.
-Steve
