🚀 go-pugleaf

In article <1cpssnINN3bj@ector.cs.purdue.edu> gb@cs.purdue.edu (Gerald Baumgartner) writes:
>In article <1992Oct29.195546.1@vax1.bham.ac.uk> mccauleyba@vax1.bham.ac.uk writes:
>
>I think the key is to view `const' as a `location specifier' instead of
>a `type specifier'.  

	No, IMHO it is an 'access specifier'. Const in C++ constrains
access via some mechanism, e.g. a pointer or reference, it is NOT
a property of the storage. (That would be nice to have though)

	For example:

	int x;
	int &r=x;
	const int &c=x;

	It is the access to x via c that is restricted to 'const',
not the storage location (variable). In fact I think that x is
just a reference like r that happens to also allocate storage.

>
>But does it make sense to view `const' as a type specifier?  I think
>not.  A type is, semantically, a set of values.  All of those values
>are constant.  

>Also, it just doesn't make sense to talk about a
>function returning a `const T.'  If `const' were a type specifier,
>then a function returning `const T' would need to have some kind of
>meaning.

	Same applies to parameters. f(const int) and f(int)
are senselessly distinct functions.

>
>It's only variables (or locations in general) for which a `const'
>qualification is useful.  This way we are asserting, that the value of
>this location is not allowed to change.

	You could have this facility, but 'const' is an access specifier
not a property of the storage. If one ALSO allowed the 'rom' storage
attribute you could disallow taking a non-const pointer or reference
to it.

	rom int x;
	int &y=x; /// compiler error

>
>I propose to call `const' and `volatile' `location specifiers' which
>qualify the next variable (or parameter) name or the next `*' instead
>of qualifying the next type identifier.  For example,
>
>	const T x;
>
>declares the memory location of `x' to be a readonly location, and
>
>	const T * p;
>
>declares `p' to be a pointer to a readonly location.

	This is not quite right. Const might also mean 'logical const',
it does not ensure constness cant be cast away harmlessly to
maintain a cache. So there is yet another meaning to const.
Perhaps 'rom' is a better keyword here.

>
>Now both of the examples above are safe.

	No, because one can cast away const. But we could make it
that 'rom' cannot be cast away. Alternatively, another keyword
'immutable' could mean logical const. The problem is that for 
a class 'const' applies at three levels, public protected and private.
Something can be publicaly constant but still modifiable privately.
This is not the same as the storage location being rommable, 
because even an object in rom may be publically mutable
(by changing a related store via a pointer).


-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------