Head Const

[Jonathan M Davis via Digitalmars-d]

On Friday, 19 February 2016 at 05:33:54 UTC, Doc wrote:
> 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.

The mutable keyword is used for stuff that frequently _isn't_ 
part of the API of a type and thus doing something with 
interfaces doesn't make a lot of sense to me. And it's really the 
type that's constructed that needs to clearly have mutable 
members, not the interface, because the key thing is to avoid 
constructing immutable variables of that type. In addition, 
interfaces only apply to classes, which is far too limiting, even 
if it's otherwise a good idea.

Having @mutable would not result in @mutable being plastered 
everywhere in D anymore than mutable is in C++. If someone used 
it that much, then there isn't much point in using const in the 
first place. Rather, certain types will have @mutable on at most 
a few of their members, and they'll have to have @mutable on the 
type itself (or something like @has_mutable if it's problematic 
to reuse the same attribute on the type), so it'll be obvious 
when it's used and will prevent the compiler from constructing 
such objects as immutable, since that would break immutability. I 
wouldn't expect it to be intrusive at all, but it's critical for 
certain types of objects to work with const at all, and if those 
objects don't work with const, then the code bases that they're 
in will avoid const, and generic code will be forced to avoid 
const regardless, because it could be used with most anything - 
including stuff that can't be const, whereas if we had @mutable, 
that problem would be reduced considerably and maybe even 
eliminated.

- Jonathan M Davis