Why D const is annoying

[Chris Cain]

On Wednesday, 2 May 2012 at 06:10:04 UTC, Mehrdad wrote:
> I don't think you answered my question.
>
> What I said (or meant to ask) was this:
> - OK, FINE, let's say I don't know what D's const() means, 
> then. Maybe it isn't suitable for what I need. I just want to 
> know:
>  _How do you specify that the function process1() won't modify 
> its 'student' parameter_?

If you want just to specify that (and not ask the compiler to 
check for you), documentation will do.

>
> Your response was this:
> - "Does const(Student) mean that it shouldn't write to the 
> server?"
>
> To which my answer is:
> - I don't know, you tell me. (?) _Should_ I use 'const' to 
> specify this? Or should I use something else?

I can't tell you what you want. You have to tell me. But no, you 
shouldn't use const to specify this. const means you're object 
won't be changed by you. Here's a decision tree for if you can 
use const and immutable

Will the object (including all of its fields) ever change?
no -> immutable (END)
yes ->
Will the object (including all of its fields) be changed by you?
no -> const (END)
yes -> No qualifier

That's _any_ kind of modification of state. If you change state, 
you can't use immutable/const (nor would you really want to).

> The problem with your answer is that it implies D DOESN'T 
> SUPPORT O.O.P. with const!!!
>
> If D supported OOP, then why the heck would process1() know (or 
> _care_) how Student works internally?
> Why (or how) should it know (or care) that Student uses a 
> database connection?

When you say "const(Student)" you're saying that whatever Student 
does, you want to know whatever you do won't change its internal 
state.

I'm not sure you're using OOP properly. If you want to use OOP to 
solve the problem, my suggestion is closer to OOP than using 
const. If you don't want to talk about database connections and 
everything (i.e., you don't want to use D's outrageously nice 
templates), you can just have it be an interface instead. In fact 
an interface would probably be more appropriate.

interface ROStudent {
    getName();
    getAddress();
    ...
}

process1(ROStudent student);

Effectively, though, it's the same sort of thing.

D's const/immutable require a different way of thinking of it. 
What are they useful for? Consider a multithreaded program where 
some threads depend on information that others have. They need 
the information but they won't change state (which makes it much 
safer/faster to work with because locking isn't as necessary ... 
with immutable locking is actually silly). That's what 
const/immutable is for.

In C++, you'd be foolish to not have locks set up even for const 
variables because they can change at any time for any reason. 
It's hardly a guarantee and it's so common to violate (look at 
yourself, for instance) that it means _nothing_. I liked how it 
was described as a glorified comment, because that's precisely 
how I think of it.

> Wasn't that information an implementation detail?
>
>
> All process1() needs to know is the *PUBLIC INTERFACE* of 
> Student.
> And all it cares to say is: "According to the public interface 
> of Student, none of the methods I will use will modify the 
> object."
> process1() has NO IDEA what goes on internally! It has NO IDEA 
> that Student uses a database connection. Maybe it's a network 
> connnection instead. Or maybe it's being unit-tested, and it's 
> actually a dummy object, with no relation to the outside world. 
> Or maybe it's a wrapper/proxy for another object.
>
> The point is: _why should the code for process1() depend on 
> this_?!

If that's what you want, then that's precisely what D does. 
"According to the public interface of Student, none of the 
methods I will use will modify the object." As opposed to C++'s 
method of "According to the public interface of student, these 
methods have comments that say that they say they won't change 
the object, but I can't tell if it does or not."

Again, using an interface ROStudent/StudentReader/etc is really 
your "OOP solution".

>
>
>
>
> So, I'll ask my question again:
>
> How should process1() tell the outside world that it will not 
> be asking its parameter to manipulate itself, WITHOUT breaking 
> the abstraction barrier and 'peeking' into the private world of 
> Student?

I'll respond again: It depends on what you want. If you won't be 
changing the object, then const/immutable does that. If you will 
be changing the object, but you want guarantees that it won't 
write to some external source/data structure, you'll have to come 
up with the more precise way you want to define that. I gave you 
two potential approaches.


----

Really though, the C++ way is a complete and total minefield in 
this regard anyway. Consider Student defined like so:

Student {
name, id, address, phone_number;
connection;
getName() const {
     if(!name) {
         // cast away const
         thisnonconst.name = connection.get("name");
     }
     return name;
}
writeName() {
     connection.set("name", name);
}
}

Now this follows one particular understanding of const (the one I 
think you're getting at). However, imagine another person comes 
along and sees that "writeName" doesn't write to Student's state. 
Helpfully, he adds const to the end of writeName and breaks your 
type system. In fact, it's actually _easier_ to violate "that 
kind of const" than it is to use it, because your "getName" 
method has to do fancy casting away of const.

In fact, D's way, if you specify that Student can only use a 
ReadOnlyConnection (or if you use ROStudent/StudentReader 
interface), then the compiler will guarantee that it has a 
ReadOnlyConnection. If ReadOnlyConnection doesn't write to the 
database, then that Student is _guaranteed_ to not write to the 
database.

If you want the compiler to check that, the D offers the ability 
to. C++, on the other hand (using const), can barely suggest that 
possibility, since it's so easy to violate.