Clarifying 'const' terminology

[Kirk McDonald]

Bruno Medeiros wrote:
> Derek Parnell wrote:
> 
>> I'm not from a C++/C#/Java background, so please excuse my lack of 
>> understanding about the meaning that is being applied to the term 
>> 'const' in these recent discussions.
>>
> 
> I think many times people talked a bit vaguely with their meaning of const.
> 
>> To me, there seems to be two things being talked about.
>>
>> (a) Data, which once initialized, is not to be modified for the 
>> run-time life of the application.
>>
>> (b) Data, which once passed to some function, is not to be modified 
>> for the run-time life of that function.
>>
>> Walter's proposed refinement of the 'in' keyword does nothing for type 
>> (a), and only limited support for type (b), in that it protects data 
>> from the called function but not from functions that that subsequently 
>> calls. It is only protection for one level deep. And the only data 
>> protected is class objects and not other reference types.
>>
>> Is there any other types (or subtypes) of 'const' meanings being 
>> discussed or considered?
>>
>> For example, are we distinguishing between compile-time protection and 
>> run-time protection?
>>
> 
> 'const', in a general sense, is a mechanism to specify whether a 
> variable/data/object can or can not modified, and enforce that contract 
> (at compile time). 'const' is usually in the sense of (b), that is, some 
> parts of code may modify the data, while others can only read it (thus 
> it is used for ownership management). That's the case for C++.
> Enforcing the contract means you cannot assign a const variable to a 
> non-const one, or similarly, pass a const variable to a function that 
> expects a non-const argument. The only way to subvert this is with a 
> cast (which should be the only way to subvert anything).
> 
> There are some variations in const semantics. In C++, const is a 
> type-modifier, meaning that const can be applied to each type element, 
> and not the "variable as whole". Best to give an example. In C++ you can 
> have:
>   const int * iptr = ...;
>   int const * iptr = ...;
>   const int const * iptr = ...;
> each with different meanings:
> 
>   const int * iptr = ...;
>   // cannot modify the pointed int, can modify the pointer
> 
>   int const * iptr = ...;
>   // can modify the pointed int, cannot modify the pointer (the pointer 
> is const)
> 
>   const int const * iptr = ...;
>   // Cannot modify the pointed int, nor cannot modify the pointer
> 

There's another place you can put 'const' in C++:

class A {
     void bar(int i);
     int foo() const;
};

This "const" ensures that the member function A::foo does not modify the 
instance of A that you are calling it on. (If the function does do so, 
it is a compile error.) This is an issue when you are dealing with const 
instances of A:

const A a;

a.bar(12); // ERROR! a is const, A::bar is not
a.foo();   // Okay

I actually view this as necessary if we get a way to declare an instance 
as immutable in D. (Honestly, I have few issues with C++ const, though 
this "const-by-default for class instances" idea has merit, too.)

> In this usual meaning (C++), there are no guarantees that the data will 
> not actually change (by someone else for example) or that it is a 
> compile constant. (That is why I say the use of this notion of const is 
> for ownership management).
> 
> In D, 'const' is not a type modifier but what Walter calls a "storage 
> modifier" (or storage attribute), but I think "variable modifier" is 
> perhaps a better term. D's const is applied not to each of many possible 
> type elements, but to the whole variable, like private or other 
> protection attributes (and as such there can be only one const per 
> declaration). D's const also has two different meanings (a bad thing 
> IMO), and they're both different from C++'s:
> 
> * const var declaration with an initializer:
> -> the value of the variable is a compile time constant. The variable 
> has no storage, it becomes an alias for it's initializer literal. (and 
> has such one can't take the address of it)
> 
> * const var declaration without an initializer:
> -> the var can be initialized in constructors only, and on all other 
> places it's value is read-only. The variable has normal storage. This is 
> what is (much more properly) called 'final' in other languages.
> 
> There are some more possible variations. There can be a const that has 
> the same meaning as C++'s (you cannot change the var), but which is a 
> variable modifier instead of a type modifier. But in this case there is 
> a prominent issue of whether the read-only/immutability property is 
> transitive or not. For example (calling this behavior 'readonly'):
>   readonly int **ptr;
> Can one change *ptr and **ptr ? Or just ptr?
> 
> And there are quite some more issues to consider when implementing a 
> 'const' mechanism such as this one. (see below)
> 
>> My requirements for 'const' are almost covered by Walter's new 
>> proposal. I'm a quite concerned that if I tell Foo() that it can't 
>> change something, that Foo() can still tell Bar() to disregard my 
>> request and tell Bar() that it's okay to change it anyway.
>>
>> I think that apart from array references, type (a) const can be 
>> acheived through using private members and public properties. I'm not 
>> sure how we can fully implement (a) with current D semantics.
>>
>> --Derek Parnell
>> Melbourne, Australia
> 
> 
> I'm assuming that in that that last "(a)" you meant "(b)".
> Implementing a mechanism such as this is actually quite complex (in 
> terms of design itself) because of several special cases which need more 
> language constructs. It's not just adding the "immutable" keyword as 
> some people seem to think.
> To know what I'm talking about exactly one should read this quite 
> informative paper:
> http://pag.csail.mit.edu/pubs/ref-immutability-oopsla2005-abstract.html
> I haven't read it all yet, but I plan to do so soon, since everyone is 
> talking about const again. And I would say reading it should likely be 
> mandatory for anyone who wants to venture thinking and posting how the 
> const system should work. It describes the issues one faces when 
> implementing such a system, and the reference immutability system 
> described there is perhaps a good starting point for a system for D.
> 


-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki