On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The more I look at it, the more I'm inclined to think that
introducing @mutable for member variables with a corresponding,
required attribute on the struct or class it's in (e.g.
@has_mutable) is really what we need to be able to solve this
problem and make D usable in some of these high performance
cases that would be using the mutable keyword in C++. It solves
the logical const problem without totally throwing away the
compiler guarantees. Any type without @has_mutable functions as
it always has, and the cases where @mutable/@has_mutable would
be required would then work with const, gaining all of its
benefits for the non-@mutable members, and it would allow the
compiler to prevent you from doing stupid stuff like mutating
immutable objects, because an object with @has_mutable couldn't
be immutable.
- Jonathan M Davis
Could we use a special class Interface for this to limit the
widespread use of a new keyword or attribute?
I.e. classes could implement a special mutable RefCount (as an
example) interface. Only code that refers to the object by it's
mutable interface would be allowed to jailbreak its overall
constness, and only for those members defined in the mutable
interface.
Maybe add a MutableInterface keyword or an attribute strictly
valid in Interface declarations.
Just a late night brainstorm.
-Doc
