August 17, 2012
On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
> Also, if the only view of the data you have is that const view, it's effectively the same as immutable (it couldn't be changed by any valid code).


So you're saying casting away a const _pointer_ is undefined, even if the target was originally created as mutable. (Otherwise, the code would certainly be "valid", just like in C++.)


Which means you can effectively _never_ cast away constness of a pointer/reference, no matter how certain you are about the target object, right?

If you did, then the code would be invalid, and the compiler could simply format your C: drive instead of modifying the object.

If so, then why is such an undefined cast allowed in the first place?
August 17, 2012
On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
> He was clearly _not_ talking about modifying the pointer.
> He said you cannot alter the "elements pointed TO".
>
>
> Given that, I have no idea how that is supposed to be saying "you can't modify the const _view_". He's clearly talking about the target of the pointer, not the pointer itself.

I'll let Mr. Davis confirm which he was talking about. The only thing that's clear is that our understandings of his point differ.
August 17, 2012
On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
> So you're saying casting away a const _pointer_ is undefined, even if the target was originally created as mutable. (Otherwise, the code would certainly be "valid", just like in C++.)
>
>
> Which means you can effectively _never_ cast away constness of a pointer/reference, no matter how certain you are about the target object, right?
>
> If you did, then the code would be invalid, and the compiler could simply format your C: drive instead of modifying the object.
>
> If so, then why is such an undefined cast allowed in the first place?

If you're absolutely 100% completely totally certain that the data is mutable (i.e., you have confirmed either through good, sound reasoning OR you have some method of seeing exactly where it is stored in your RAM and you've checked that the place it is stored is writable memory), then __technically__, yes you can cast away and modify away. Apparently, according to some, it's necessary for low level programming. I'd highly discourage this type of behavior because if you're doing something like that I'm nearly certain you could come up with a better design, not to mention you're missing the point of having something const in the first place.

Let's just say I wouldn't use const in a place where I'm itching to cast it away. If you're not going to use it to your advantage, there's no point.
August 17, 2012
On Friday, 17 August 2012 at 01:50:02 UTC, Chris Cain wrote:
> On Friday, 17 August 2012 at 01:43:03 UTC, Mehrdad wrote:
>> Isn't that kinda useless, if it tells you nothing about the object itself?
>
> Not sure what your point is. It tells you enough about how you work with that "object itself"


Are you sure?



struct MyStruct
{
	static int* x;
	int y;

	this() { }
	this(int* z) { x = z; }

	auto getValue() const
	{
		++*x;
		return this.y;
	}
}

auto s = MyStruct();
s = MyStruct(&s.y);

s.getValue();  // const, but returns 1
s.getValue();  // const, but returns 2
s.getValue();  // const, but returns 3



So, effectively, the mere const-ness (and even its transitivity) is useless to the compiler.



> I'll let Mr. Davis confirm which he was talking about. The only thing that's clear is that our understandings of his point differ.

Okay sure, thanks for trying to explain it anyway!
August 17, 2012
On Friday, August 17, 2012 03:52:38 Chris Cain wrote:
> On Friday, 17 August 2012 at 01:45:27 UTC, Mehrdad wrote:
> > He was clearly _not_ talking about modifying the pointer. He said you cannot alter the "elements pointed TO".
> > 
> > 
> > Given that, I have no idea how that is supposed to be saying "you can't modify the const _view_". He's clearly talking about the target of the pointer, not the pointer itself.
> 
> I'll let Mr. Davis confirm which he was talking about. The only thing that's clear is that our understandings of his point differ.

If you have a const object, then you have the guarantee that none of what it contains or refers to either directly or indirectly can be altered through that reference or pointer. It's possible to alter it via other references, and without pure, const functions called on that object may still be able to alter by using global variables, but you do have the guarantee that that object and anything and everything that it refers to won't be directly mutated by that reference.

- Jonathan M Davis
August 17, 2012
On Friday, August 17, 2012 03:51:36 Mehrdad wrote:
> On Friday, 17 August 2012 at 01:33:29 UTC, Chris Cain wrote:
> > Also, if the only view of the data you have is that const view, it's effectively the same as immutable (it couldn't be changed by any valid code).
> 
> So you're saying casting away a const _pointer_ is undefined, even if the target was originally created as mutable. (Otherwise, the code would certainly be "valid", just like in C++.)
> 
> 
> Which means you can effectively _never_ cast away constness of a pointer/reference, no matter how certain you are about the target object, right?
> 
> If you did, then the code would be invalid, and the compiler could simply format your C: drive instead of modifying the object.
> 
> If so, then why is such an undefined cast allowed in the first place?

Because there are plenty of functions which take mutable objects but don't actually alter them - particularly when interacting with C code. It's the sort of thing that you really shouldn't be doing normally but on rare occasions is useful - in this case when dealing with code that isn't const correct but still won't actually alter the object.

- Jonathan M Davis
August 17, 2012
On Friday, August 17, 2012 03:00:34 Chris Cain wrote:
> On Friday, 17 August 2012 at 00:44:20 UTC, Chris Cain wrote:
> > Also, D's const is _not_ a guarantee that there are no mutable references to something. That'd be immutable.
> 
> And, by the way, I'd call this a bug (not sure if reported yet):
> 
> 
> 
> int yourGlobalCounter;
> 
> struct S
> {
> int*[] items;
> 
> this(int i)
> {
> items = new int*[1];
> items[0] = &yourGlobalCounter;
> yourGlobalCounter = i;
> }
> 
> ref const(int*[]) getItems() const
> {
> ++yourGlobalCounter;
> return items;
> }
> }
> 
> import std.stdio;
> 
> void main() {
> immutable(S) s = immutable(S)(0);
> auto it = s.getItems();
> writeln(*it[0]);
> s.getItems();
> writeln(*it[0]);
> }

How is it a bug? The variable that you're altering is not part of the object. That's part of why having pure with const in so valuable. It prevents stuff like what you're doing here.

- Jonathan M Davis
August 17, 2012
On Friday, 17 August 2012 at 01:59:03 UTC, Chris Cain wrote:
> On Friday, 17 August 2012 at 01:51:38 UTC, Mehrdad wrote:
>> So you're saying casting away a const _pointer_ is undefined, even if the target was originally created as mutable. (Otherwise, the code would certainly be "valid", just like in C++.)
>>
>>
>> Which means you can effectively _never_ cast away constness of a pointer/reference, no matter how certain you are about the target object, right?
>>
>> If you did, then the code would be invalid, and the compiler could simply format your C: drive instead of modifying the object.
>>
>> If so, then why is such an undefined cast allowed in the first place?
>
> If you're absolutely 100% completely totally certain that the data is mutable (i.e., you have confirmed either through good, sound reasoning OR you have some method of seeing exactly where it is stored in your RAM and you've checked that the place it is stored is writable memory), then __technically__, yes you can cast away and modify away.





If doing so is "invalid" (i.e. undefined?) like you mentioned, no, you can't, because the compiler can't guarantee it can respect your assumptions and generate otherwise-correct code.

If it IS valid, then it seems to me like the situation is the exact same with C++.
August 17, 2012
On Friday, 17 August 2012 at 02:02:56 UTC, Jonathan M Davis wrote:
> How is it a bug? The variable that you're altering is not part of the object.


It doesn't need to be.


What you said was:



> If you have a const object, then you have the guarantee that none of what it contains or refers to ____either directly or indirectly_____ can be altered through that reference or pointer.


But as I just showed, it can, so... yeah.



> That's part of why having pure with const in so valuable.

Right, but purity is another topic. :)
August 17, 2012
On Friday, 17 August 2012 at 02:02:51 UTC, Jonathan M Davis wrote:
> Because there are plenty of functions which take mutable objects but don't actually alter them - particularly when interacting with C code.



Ah, so that explains that, thanks.

So to clarify, modifying a mutable object through casting away a const reference is undefined in D, but valid in C++.

Now the only question is what guarantees that actually gives you that the compiler can use for optimization (aliasing issue above^).