Pointed out to me by @achernya: what makes things tricky is that there is really common confusion about the precedence of const in an expression like const int*. The correct parsing is not "this is a const (int pointer)" but "this is a pointer to a (const int)". And this is why int* const is the actual way you spell "const pointer to an int".

Now, the problem is that Tensor morally expands to pointer to a (non-const) TensorImpl. And so if you say const Tensor, now the precedence goes the way you expect: you have a const (pointer to a (non-const) TensorImpl), which is not at all the same thing as const TensorImpl*. But this makes all the difference: the correct semantics for const Tensor lets you still mutate the underlying TensorImpl: it's just the pointer itself that's const.

This also explains why the following idea doesn't work: what if we hid the (mutable) TensorImpl pointer as private data, and provided only methods which enforced const-correctness? You could, but you'd be forced to take out the copy constructor. Otherwise, you can write this:

Tensor unconst(const Tensor& x) {
  return x;
}

C++ will happily copy construct a non-const Tensor from a const one, because, hey, it's a copy constructor, it does a semantic copy, right? But Tensor's copy constructor does nothing of this kind.

Const-correctness #27

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions