Head Const

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 16 00:04:32 PST 2016


On Tuesday, 16 February 2016 at 07:20:00 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright 
> wrote:
>> rears its head again :-)
>>
>> Head Const is what C++ has for const, i.e. it is not 
>> transitive, applies to one level only. D has transitive const.
>>
>> What head const will do for us:
>>
>> 1. make it easy to interface to C++ code that uses const, as 
>> currently it is not very practical to do so, you have to 
>> resort to pragma(mangle)
>>
>> 2. supports single assignment style of programming, even if 
>> the data is otherwise mutable
>>
>> The downside is, of course, language complexity.
>
> Maybe you can get away with adding "mutable", which is needed 
> for intrusive ref counting as well:
>
> C++:
> Type * const ptr;
>
> struct ConstType {
> mutable int rc;
> }
>
>
> D:
> const mutable(Type)* ptr;
>
> struct ConstType {
> mutable(int) rc;
> }

For that to work in D, we'd lose out on the guarantee that a 
const object can't be mutated via a const reference to that data 
- though with the current state of things, const does become 
limiting enough that you can't use it under a number of 
circumstances that you might like to (e.g. ref-counting), and 
some folks mistakenly think that it's defined behavior to cast 
away const and mutate and do it in their code. So, such a change 
might be worth it, but it's not something that should be 
considered lightly. If we did go that route though, having 
mutable or @mutable would allow for it to be much more controlled 
than simply casting away const and mutating (e.g. it could 
guarantee that no immutable objects were involved, since an 
object with an @mutable member couldn't be immutable, since that 
would violate immutable).

But even if we went that route, that's still a whole other 
ballgame from non-transitive const. There are some major 
implications for const if we making it legal to cast it away and 
mutate as long as the underlying data is mutable rather than 
immutable, but from a language complexity standpoint, it's not 
particularly problematic, whereas non-transitive const is.

- Jonathan M Davis


More information about the Digitalmars-d mailing list