What guarantees does D 'const' provide, compared to C++?

[Mehrdad]

On Friday, 17 August 2012 at 00:10:52 UTC, Jonathan M Davis wrote:
> In C++, if you have
>
> const vector<T*>& getStuff() const;
>
> which returns a member variable, then as long as const isn't 
> cast away, you know that the container itself won't have any 
> elements added or removed from it, but you have _zero_ 
> guarantees about the elements themselves.

Right.


> In contrast, in D,
>
> const ref Array!(T*) getStuff() const;
>
> you would _know_ that not only is the container not altered,
> but you know that the elements aren't altered either -
> or anything which the elements point to.


I'm not so sure about that.

int yourGlobalCounter;

struct MyIntPtrArray
{
	int*[] items;

	MyIntPtrArray()
	{
		items = new int*[1];
		items[0] = &yourGlobalField;
	}

	ref const(int*[]) getItems() const
	{
		++yourGlobalCounter;
		return items;
	}
}


> And since casting away const and mutating a variable is 
> undefined behavior,

That is either vague, or contradicts what I was told above.
We all know casting away a const _object_ is undefined behavior 
in both D and C++.
However, is casting away a const __reference__ undefined behavior 
in D? (It's not in C++.)


>> > The compiler will guarantee you aren't changing data that is 
>> > const.
>> 
>> Right, but it's the same with C++, right? Where's the 
>> difference?
>
> C++ makes no such guarantees, because you're free to cast away 
> const and modifiy objects


Not correct, as far as I understand.
C++ only lets you cast away _const references_ to _mutable_ 
objects.
If the object happens to have been const _itself_, then that's 
undefined behavior.


> and because objects can have members marked with the mutable 
> keyword.

Right, it's the equivalent of static fields, see my example above.





>> > On the note of casting away const, I don't believe that is 
>> > the operation which is undefined, however modifying const is 
>> > undefined as it could be pointing to immutable data.
>> Oh, then that's not what I'd understood. Seems just like C++ 
>> then.
>
> No. Casting away const and modifying an object is well-defined 
> in C++.


Only if the object was mutable to begin with. See above.





> const is useful even without purity, because you _know_ that 
> nothing which is const can change unless you access it through 
> a non-const reference


Yeah, and as I just showed, aliasing messes this up just as badly 
as in C++. See above.


> Now, it _does_ get far better once purity is added into the mix
> And of course, immutable offers even better guarantees

Yup, I agree about those; I'm just referring to const here.