Why can't a reference's target object be reasigned?

Question

If I understand correctly, the motivation of references was to make it easier and cleaner to work "by reference" without having to bother with pointer dereferencing. But they are constant in nature, they can only point to a single object, even if effectively a reference is a pointer and reassigning is technically possible. It would also seem beneficial if a reference can be null, e.g. check if a returned reference is valid before using it, but this is not a feature.

What might be the particular motivation behind omitting such features and presenting the feature as it is?

Answer 1

1. If you want to reference multiple objects, you just need a different TYPE of reference.
2. If you want to be able to change the reference itself (and not just what it refers to), you want a pointer. Ditto for a reference that might not refer to anything (i.e. be null).

So that's the motivation: focus on what can't already be done through other means.

Answer 2

References being non-nullable is a good thing, it allows you to make stronger guarantees about the input to you're functions and so on. It allows you to pass objects without having to do a null pointer test.

If you want a mutable reference use either a pointer or a std::reference_wrapper. If you want an optional return value then you can use something like boost::optional.

Answer 3

There are two parts to the motivation:

1) A reference is conceptually an alias for an object, so it behaves (as much as is possible and useful) like a variable name. For as long as it is in scope it refers to the same object, and it always does refer to an object. So, not re-seatable and not null.

2) References were invented for the purpose of passing parameters to overloaded operators. There's no particular need to re-seat such parameters, and they certainly must always refer to an object because the operator always has operands (or just one operand for unary operators). The feature that suited the need was an alias for the operand, and that is why references were conceived as aliases.

Having been conceived that way, they have other uses. None of those uses would benefit enough from them being re-seatable or being null, to make a case for changing the concept away from an object name. The one that comes closest is probably their use as non-static data members in classes. In that case they interfere with things like copy assignment, but then again it is not clear how a reference data member "should" behave when copy-assigned, so there's no clear-cut way to deal with it. Pointers will deal with the cases that references can't.

Answer 4

I'd say the restrictions on what can be done with references are there, because it allows:

• the compiler to do strict checking on the valid use of references, giving compile-time safety when using references in most situation
• more complex operations can still be done using regular pointers

So pointers are for situations when you know you want to do tricky stuff with them. References are for the typical case of `I just want to hand a piece of data around' without having to worry much about doing it right.