I get how. I don't get why. (more const stuff)

Janice Caron caron at serenityfirefly.com
Fri Sep 7 06:51:16 PDT 2007


-----Original Message-----
From: digitalmars-d-bounces at puremagic.com 
[mailto:digitalmars-d-bounces at puremagic.com] On Behalf Of Daniel Keep
Sent: 07 September 2007 13:48
To: digitalmars-d at puremagic.com
Subject: Re: What is the difference between...

> I get the feeling you haven't read the various articles on how
> const works in D 2.0...

Then your feeling is completely incorrect. I have read everything on the 
DigitalMars website many times over. And I'm also not dumb - before you go 
suggesting that. The problem is, the webpage just doesn't do a particularly 
good job of explaining things. (But fortunately, you do, funnily enough).

Of course, I've only actually /had/ D2.0 on my PC for a couple of hours, so 
before that, I couldn't play with it, and was limited to /only/ reading the 
docs.



> 2. "const" (storage class) -- makes a variable's bits immutable at
> compile time, and transitively adds const(T) to the stored type.
>
> 4. "const(T)" (type constructor) -- turns any reference type T
> into a read-only view of the referenced data; has no effect on non-reference 
> types.

Yes, I understant that now, since you explained it in your last email. Though I 
have to confess, I still don't understand the reasons behind this choice.

Basically, I don't understand why anyone thought it would be a good idea for 
const(T) to mean something different, depending on whether T was a class or a 
struct. I'm trying really hard to get this, but I just don't understand why 
Walter would define const(S), where S is a struct, to mean that S is mutable.

Walter, if you're reading this, could you, like, tell me?



> Yes, it's weird when you first see it,
> but there are good reasons for it being the way it is.

OK, so there are good reasons why "const(T) x" means that x is mutable if T is 
a struct, but not if T is a class. I believe you. I really do. But ... I don't 
actually know what those good reasons /are/. I'd really like to know what they 
are.


> http://www.digitalmars.com/d/const.html

Obviously, I read that before posting here.


> http://while-nan.blogspot.com/2007/06/you-cant-touch-this.html

Well yes, I understand the concepts, but the article didn't know what the 
syntax was going to be, and so is ill-equipt to explain why the syntax is what 
it is.


It just seems to me that, had it been defined differently - for example, 
suppose that "const(T) x" meant that x was immutable, and that anything 
referenced by x (transitively) was also immutable, then it all would have made 
sense. There would have been no need for "const T x" to even exist, and there 
would have been no reason for "const(T) x" to behave differently depending on 
whether T is a class or a struct. As you say, there probably were good reasons 
for not doing that, but I'm blowed if I can see what they are.






More information about the Digitalmars-d mailing list