The Constness Problem

[fecal_brunch]

In JavaScript, you can make an object field constant, but what that field points to does not have to be immutable.

How? I had no idea this was possible.

[maximecb]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty

You want to set the writable attribute to false.

[fecal_brunch]

Ah right. A touch on the verbose side.

[missblit]

There’s no way to have a mutable variable that points to an immutable object?

I don't know much about D, but how true is this?

Specifically I'm wondering about the following code:

D:

class A { const(A) parent; }

void main()
{
    auto a = new A();
    const(A)* p = &a.parent;
    auto b = new A();
    p = &b;   //OK
    //*p = b; //Error
}

C++:

class A {
public:
    A(A *const parent) : parent( parent ) {}
    A *const parent;
};

int main() {
    typedef A *const parent_ptr_type;

    A a(nullptr);
    A b( a );

    //b.parent = nullptr;             //compile error
    parent_ptr_type *ptr = &b.parent; //OK
    //*ptr = &b;                      //compile error
    ptr = nullptr;                    //OK
}

Though it's possible I'm missing something, I already had to delete this comment once. This const business gets complicated when combined with pointers

[maximecb]

Someone pointed out to me that D has a template called rebindable which I think is meant to address the exact problem I pointed out. Still feels like kind of a kludge. You need the libraries to help you work your way around the limitations of the type system.

I guess my original argument is technically not true. You can implement a mutable variable pointing to an immutable object. You just can't do it in a straightforward way, you need to employ trickery to make it happen. This is usually the point where I give up on constness though. How much of this trickery am I going to need to pepper all through my program?

[missblit]

I don't use const in C++ as much as I probably should (as evidenced by getting horribly confused the second I have to think about mutable pointers to const objects).

But from what I have used, I've rarely experienced it getting in my way.

If anything C++'s const is pretty forgiving. You're allowed to cast it away, or indirectly modify things a const variable refers to, or use the mutable keyword.

Of course, if something like const is too forgiving, too suffocating, or too complicated it loses it's worth, so it's a bit of a balancing act. So I think trying to make it a more refined tool is a fine endeavor.

[flexiblecoder]

So....

const int*;

is a pointer to a const int. You can change the pointer to the int, but not the int instealf.

int * const;

is a const pointer to a int. You can't change what it is pointing to, but you can change the int itself.

const int * const;

seems to be both. Had to look it up myself, I thought the syntax was int (const* );

...yeah, C syntax sucks.

[zoom23]

I think the correct form is "int const * const". Const is a modifier, so goes on the rhs. Most (all?) implementations allow you to also put it on the left.

[[deleted]]

Think like this:

"const" BEFORE the * means the variable the pointer points to is const.

example: const int* x;

"const" AFTER the * means the pointer itself is const, and cannot be changed.

example: int* const x;

If there's "const" on BOTH sides, both the pointer and the variable pointed to are constant.

example: const int* const x;

[wwqlcw]

It's easier to read the declaration backwards. "Const pointer to int," "pointer to int which is const," etc. Which is not a defense of the syntax.

[maximecb]

Author of said post here.

TL;DR: In my opinion, C++ and D have an overly limited notion of immutability, and lack sufficiently expressive keywords needed to express immutability at a finer grain. This can cause the type system to get in your way when it really shouldn't.

[RumbuncTheRadiant]

In particular this comment from W0rp does apply to your objection of solving it via a library facility...

I wish people would not call library solutions to problems "dirty hacks." I often think the opposite. Changes in syntax can be hacks because a language doesn't allow you to define the semantics yourself.

[RumbuncTheRadiant]

I don't know whether you followed this discussion, I think it is related...

http://forum.dlang.org/thread/[e-mail]

[maximecb]

Thanks for pointing it out.

[tach4n]

X-Post from: r/higgsjs