🚀 go-pugleaf

In article <1993Jan10.162757.1097@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:


jss:
|> >You're right.  I knew about that loophole, but forgot about it when
|> >I posted my original item.  If anyone has ideas for a clean way
|> >to close this loophole, I'd be interested to hear them.  
|> 

maxtal:
|> 	Do we want to close it?


I do.

jss:
|> >
|> >The problem is that the object is only "marked" immutable when the
|> >constructor returns.  The constructor itself is supposed to be free
|> >to modify the object in any way it chooses.

maxtal:
|> 
|> 	The problem is that the object is *never* marked const.
|> What is made const is the 'reference' or pointer to the object.

The original item explained that "marking" wasn't actually caried
out a runtime, but the concept is useful in explaining the intentions
of the type system.

To repeat. The desired (by me) property (with slightly more
explicit wording than the original and avoiding the use of "mark's")
is 

	If an object is constructed const(immutable), then
	between the time that the constructor (if any) completes
        and the destructor (if any) is called (if ever) the
        type system should guarantee that any expression that refers to 
        this object or a subobject of it will do so via
        const(qualified) type.  

I use const(immutable) to indicate a property of an object, and
const(qualified) to indicate a property of a type.

This is a desirable property whether or not "const" has any effect
on the primitives, and whether or not the language specifies the
effect of modifying a const(immutable) object.

Anything that permits violation of this property is a "loophole".

The rest of maxtal's discussion concerned the meaning of "const",
which is a different subject altogether.

   -- Jerry Schwarz