• "Janice Caron" <caron serenityfirefly.com> Sep 07 2007
• Daniel919 <Daniel919 web.de> Sep 07 2007
• Daniel Keep <daniel.keep.lists gmail.com> Sep 07 2007
• Sean Kelly <sean f4.ca> Sep 07 2007
• Sean Kelly <sean f4.ca> Sep 07 2007
• Sean Kelly <sean f4.ca> Sep 07 2007

"Janice Caron" <caron serenityfirefly.com> writes:

Even more simply put, what is the difference between:

(1) void f(const int x)
(2) void f(const(int) x)
(3) void f(const const(int) x)

Just trying to get my head around this!

Daniel919 <Daniel919 web.de> writes:

Janice Caron schrieb:
 Even more simply put, what is the difference between:
 
 (1) void f(const int x)



 (2) void f(const(int) x)



 (3) void f(const const(int) x)

Daniel Keep <daniel.keep.lists gmail.com> writes:

IIRC...

Janice Caron wrote:
 Even more simply put, what is the difference between:
 
 (1) void f(const int x)


That's const as a storage class: the bits of 'x' are immutable.

 (2) void f(const(int) x)


const as a type constructor: in this case, nothing happens since
const(T) only has an effect on reference types.  Let's change it to

 (2) void f(const(int*) x)


Ok, now you've got a mutable read-only view: the bits of 'x' can be
changed, but the data referenced by x cannot.

 (3) void f(const const(int) x)


*rubs out previous line*

 (3) void f(const const(int*) x)


I suspect the const(int*) is redundant.  Since const is transitive,
const as a storage class automatically applies const-ness to the type as
well.

 Just trying to get my head around this!


	-- Daniel

Sean Kelly <sean f4.ca> writes:

Daniel Keep wrote:
 
 (2) void f(const(int*) x)


 Ok, now you've got a mutable read-only view: the bits of 'x' can be
 changed, but the data referenced by x cannot.


I thought that's what 'final' was for.  For the above, I'd expect the 
reference and the data to which it refers to both be immutable through 
x.  Is this not right?


Sean

Sean Kelly <sean f4.ca> writes:

Sean Kelly wrote:
 Daniel Keep wrote:
 (2) void f(const(int*) x)


 Ok, now you've got a mutable read-only view: the bits of 'x' can be
 changed, but the data referenced by x cannot.


 I thought that's what 'final' was for.  For the above, I'd expect the 
 reference and the data to which it refers to both be immutable through 
 x.  Is this not right?


er, let me clarify.  I would assume that:

const(int)* x

means that the data cannot be changed but the pointer can.  But by 
enclosing the pointer in parens, it should be considered constant as well.


Sean

Sean Kelly <sean f4.ca> writes:

Sean Kelly wrote:
 Sean Kelly wrote:
 Daniel Keep wrote:
 (2) void f(const(int*) x)


 Ok, now you've got a mutable read-only view: the bits of 'x' can be
 changed, but the data referenced by x cannot.


 I thought that's what 'final' was for.  For the above, I'd expect the 
 reference and the data to which it refers to both be immutable through 
 x.  Is this not right?


 er, let me clarify.  I would assume that:
 
 const(int)* x
 
 means that the data cannot be changed but the pointer can.  But by 
 enclosing the pointer in parens, it should be considered constant as well.


Forget it, I remember now.  The parenthesis means "apply this attribute 
to the type herein" and const means "can't change the data."  Out of 
curiosity, how do things work with multiple attributes:

final const(int*)* x
const final(int*)* x

I assume that both of the above are equivalent, and they mean "mutable 
pointer to an immutable pointer to immutable data."  ie. all of the 
attributes together apply to the type in parens.  Is this correct?  I'll 
admit I still find the C++ version easier to visually parse for 
non-trivial declarations--the rule is simply "apply this attribute to 
the adjacent thing on the left."  But perhaps this is because I've spent 
more time with C++ const than D const.


Sean