digitalmars.D - I get how. I don't get why. (more const stuff)
"Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message----- From: digitalmars-d-bounces puremagic.com [mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Daniel Keep Sent: 07 September 2007 13:48 To: digitalmars-d 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.
Obviously, I read that before posting here.
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.
Sep 07 2007
Gregor Richards <Richards codu.org> writes:
Disclaimer: Non D2 user :) 'const' is a compiler-defined contract to say that you won't change anything you don't own with respect to some variable. If that variable is a struct passed as an argument (and therefore passed by value), you DO own its members, but you do NOT own anything that its members point to. Restricting you from changing the content of a local variable is pointless, but const in this context would prevent you from changing anything it points to. To put it a different way: const never prevents you from changing local data, it only prevents you from writing through pointers and references. Redisclaimer: Any of this can be wrong, non D2 user :) - Gregor Richards
Sep 07 2007
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Janice Caron" wrote in messageIt 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.
I think the main confusion comes from the fact that a class reference is a pointer, even though it doesn't have a * in the definition. If you think of it this way, i.e.: const(classref) means that the classref itself is not const, but the thing it points to is. There is an implied * after the closing ')' const(structtype) * means that the structtype pointer itself is not const, but the thing that it points to is. const(structtype) means that the structtype itself is not const, and you just wasted 7 perfectly good keystrokes typing 'const()' around it since the structtype doesn't point anywhere. This makes no sense to me either... I agree that it is confusing, and I too would like to hear reasons why it is this way. To me, if you have something that looks like f(x), then x should be defined in terms of f, not f(x) * means the * outside the parentheses should be defined in terms of f, but because x is in the parentheses, it is excluded from the effects of f ??? This goes against my hard-wired mathematical brain... Although it isn't intuitive, the definition needs to be complete for the third example above. My first vote is to change the syntax. maybe something like (warning, new keyword ahead): pconst reftype x -> x is not const, but the referenced data is pconst valuetype * x -> x is not const, but the referenced data is pconst valuetype x -> compiler error, pconst cannot be applied to non-pointer types. const reftype x -> x and the referenced type are both const const ptrtype x -> x and the referenced type are both const const valuetype x -> x is const. That not being acceptable, my second vote is for const(valuetype) x generating a compiler error, as the current behavior is definitely not what the author intended. I think this would make the definition complete, even if it is counter-intuitive. -Steve
Sep 07 2007