gsl::not_null<T*> vs. std::reference_wrapper<T> vs. T&

Question

C++ Core Guidelines has been presented recently (congrats!) and I am concerned about gsl::not_null type. As stated in I.12: Declare a pointer that must not be null as not_null:

To help avoid dereferencing nullptr errors. To improve performance by avoiding redundant checks for nullptr.

...

By stating the intent in source, implementers and tools can provide better diagnostics, such as finding some classes of errors through static analysis, and perform optimizations, such as removing branches and null tests.

The intent is clear. However, we already have a language feature for that. Pointers that cannot be null are called references. And while references cannot be rebound once they are created, this problem is solved by std::reference_wrapper.

The main difference between gsl::not_null and std::reference_wrapper I see in that the latter can be used only instead of pointers, while the former works on anything nullptr-assignable (quote from F.17: Use a not_null to indicate that "null" is not a valid value):

not_null is not just for built-in pointers. It works for array_view, string_view, unique_ptr, shared_ptr, and other pointer-like types.

I imagine the feature comparison table like the following:

T&:

• Cannot store nullptr? - Yes
• Rebindable? - No
• Can be used instead of something other than pointers? - No

std::reference_wrapper<T>:

• Cannot store nullptr? - Yes
• Rebindable? - Yes
• Can be used instead of something other than pointers? - No

gsl::not_null<T*>:

• Cannot store nullptr? - Yes
• Rebindable? - Yes
• Can be used instead of something other than pointers? - Yes

Now here are the questions, finally:

1. Is my understanding of differences between these concepts correct?
2. Does that mean that std::reference_wrapper is now useless?

PS I created tags cpp-core-guidelines and guideline-support-library for this, I hope properly.

Answer 1

References are not pointers that cannot be null. References are semantically very different to pointers.

References have value assignment and comparison semantics; that is, assignment or comparison operations involving references read and write the referenced value. Pointers have (counterintuitively) reference assignment and comparison semantics; that is, assignment or comparison operations involving pointers read and write the reference itself (i.e. the address of the referenced object).

As you noted, references cannot be rebound (due to their value assignment semantics), but the reference_wrapper<T> class template can be rebound, because it has reference assignment semantics. This is because reference_wrapper<T> is designed to be used with STL containers and algorithms, and would not behave correctly if its copy assignment operator didn't do the same thing as its copy constructor. However, reference_wrapper<T> still has value comparison semantics, like a reference, so it behaves very differently to pointers when used with STL containers and algorithms. For example, set<T*> can contain pointers to different objects with the same value, while set<reference_wrapper<T>> can contain a reference to only one object with a given value.

The not_null<T*> class template has reference assignment and comparison semantics, like a pointer; it is a pointer-like type. This means that it behaves like a pointer when used with STL containers and algorithms. It just can't be null.

So, you are right in your assessment, except you forgot about comparison semantics. And no, reference_wrapper<T> will not be made obsolete by any kind of pointer-like type, because it has reference-like value comparison semantics.

Answer 2

I think that there are still use-cases for std::reference_wrapper which are not covered by gsl::not_null. Basically, std::reference_wrapper mirrors a reference and has a operator T& conversion, while not_nullhas a pointer interface with operator->. One use-case that comes to my mind immediatly is when creating a thread:

void funcWithReference(int& x) { x = 42; }
int i=0;
auto t = std::thread( funcWithReference, std::ref(i) );

If I don't have control over funcWithReference, I cannot use not_null.

The same applies to functors for algorithms, and I had to use it for binding boost::signals too.