The Status of Const

[Michel Fortin]

On 2010-08-16 10:03:58 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Mon, 16 Aug 2010 09:26:55 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> I think what you want for that is to somehow make SmartPtr!(X)  
>> implicitly derived from SmartPtr!(const X), you don't want the compiler 
>>  applying blindly tail-const to all the members.
> 
> Again, it's logical const, no matter how you slice it.

If you see it that way, then D const is logical const too. I'm not 
proposing we create a mutable island inside a const struct or class 
(thus not breaking the transitivity), so it does abide by D current 
definition of const. Here's some definition?

	struct SmartPointer(T) {
		T* pointer;
		uint* refCount;
	}

	SmartPointer!(const X) pointer;

All I am saying is that the "conceptual" tail-const form of 
SmartPointer!(X) is SmartPointer!(const X), and that it'd be useful 
that SmartPointer!(X) and SmartPointer!(immutable X) could implicitly 
cast to SmartPointer!(const X). That might be "logical const" to you as 
long as you think "tail const" for struct is "all members become tail 
const", but I think that definition of tail-const is pointless and that 
there should not be any real tail-const for structs except the one you 
can induce through its template arguments.

As for constness of ranges, it's quite similar. The thing is that you 
generally have three possible levels of constness. The range might be 
const, the container the range points to might be const, and the 
elements in the container might be const. If ranges were expressed like 
this:

	struct Range(ContainerType) {...}

then it'd be easy to say whether the container and the element type is 
const or not just like this:

	Range!(Container!(const Element))
	Range!(const Container!(immutable Element))
	Range!(immutable Container!(immutable Element))

Most ranges are not defined like this: the type of the containeris 
implied in the type of the range, but the constness of the container is 
simply missing. Wouldn't defining ranges like the above fix the 
problem? And you could make ranges cast implicitly to their 
"tail-const" form when needed, exactly like the smart pointer above.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/