Clarifying 'const' terminology

[kris]

Good idea ~ I'll have a go:

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


There are the traditional 'constant' read-only data types, assigned at 
the point of declaration (e.g. char[]s = "foo";). It used to be that 
these were located into a distinct area of memory from read/write 
program variables and so on. This was done (partly) so that the 
read-only aspect could be trapped at runtime by the executing device.

If you try to modify a D string constant on linux, you'll get a runtime 
error (Win32 D executables let you happily modify such things), so linux 
is applying read-only attributes to the segment where this constant data 
lives. However, the distinction is mostly limited to micro-controllers 
and other devices with limited RAM, but plenty of ROM -- such readonly 
constants are traditionally stored in ROM.

There's a variation on this called "final", where the constant-value is 
actually determined at runtime.  That is, you get one opportunity to 
assign a value to a final data type (such as a string) and that's it. 
Such a compiler will attach compile-time errors to additional assignments.


> (b) Data, which once passed to some function, is not to be modified for  
> the run-time life of that function.


This is the realm of where the discussion has been, vis-a-vis mutable 
and/or immutable attributes. Tis' a shame 'const' is such an overloaded term


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

Other than retaining the immutable attribute throughout a given call 
chain, the other primary subtype (I suppose) is the return value of a 
function or method.


> For example, are we distinguishing between compile-time protection and  
> run-time protection?


For the mutable/immutable aspect, I believe we're talking purely about 
the compile time aspect. To sum up the whole discussion, it's really 
about enhancing the contractual obligation between a caller and callee. 
For example:

As it stands, a callee says "I accept a string as an argument" and the 
compiler traps those cases, at compile time, where a caller does not 
provide a string: generates a compile-time error. The mutable attribute 
enhances this so the callee can say "I need a mutable string, because I 
will modify it", or "I'm happy with just an immutable string since I use 
it for read-only purposes".

A caller is then obligated to fulfill the (tighter) contract, in a 
manner similar to how it is currently obliged to provide just a string.

The benefits of doing so are numerous, and would probably dilute the 
value of establishing terminology; so we can probably leave it at that 
for now?


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


Yes, that is a notable weakness. Using an aggregate (struct or class) 
instead would give you the /propogation/ aspect required. This is in 
contrast to Walter's proposal, but requires the use of aggregates rather 
than, say, an array. BTW: this whole discussion is basically about array 
types, since others can happily be passed by value anyway.

The one problem with using aggregates in this manner is related to 
return values. For example, you can make a String struct or class and 
control what each method does to the encapsulated content. At some 
point, though, the content will likely need exposing. Perhaps via a 
toString() method or via some other means. Simply duplicating the 
content at this point is a contentious issue, so some means of tagging 
the return value as 'immutable', and having that usage enforced, would 
seem to be necessary.


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


Did you mean "... fully implement (b) with current D semantics" instead?

As I understand things, it is array references that are at stake here. I 
don't think anything else is?