Head Const

[Doc via Digitalmars-d]

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- at 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