Should `not_null<>` be two different classes? about gsl-lite

[mbeutel]

Because C++ doesn't have destructive move, we have to worried about the moved-from state. Although its occurrence cannot be statically prevented¹, not_null_1<> makes sure that the moved-from state doesn't proliferate (⇒ it checks for nullptr in all constructors), and that pointers in moved-from state are not accessed (⇒ it checks for nullptr in accessor functions such as get(), as_nullable(), operator ->()).

I realized that, for raw pointers, moving just copies, hence there is no dedicated moved-from state to worry about. In fact, the postcondition checks in get(), as_nullable(), operator ->() are unnecessary for not_null_1<T*>.

That further reduces the necessity for a type with not_null_2<> semantics; there would be no use for not_null_2<T*> because not_null_1<T*> would do exactly the same. That leaves not_null_2<SmartPtr<T>>, which could act as a semantic substitute for both not_null_1<SmartPtr<T>> const& and SmartPtr<T> const& in function arguments. The Core Guidelines give the following advice about passing smart pointers:

R.30: Take smart pointers as parameters only to explicitly express lifetime semantics
F.7: For general use, take T* or T& arguments rather than smart pointers
R.36: Take a const shared_ptr<widget>& parameter to express that it might retain a reference count to the object ???

The shared_ptr<T> const& use case is arguably a rare corner case, and std::unique_ptr<T> const& isn't mentioned and thus implicitly discouraged.

So perhaps there isn't much use for not_null_2<> at all.

[mbeutel]

I realized that, for raw pointers, moving just copies, hence there is no dedicated moved-from state to worry about. In fact, the postcondition checks in get(), as_nullable(), operator ->() are unnecessary for not_null_1<T*>.

4e0b7d2 addresses this point and adds a specialization of not_null<> for raw pointer types which elides the unnecessary checks.

[mbeutel]

Furthermore, if we ever wanted a not_null<> type with reference/borrow semantics, we could simply make gsl::not_null<> work for reference type arguments:

// std::size_t compute_hash(std::unique_ptr<Resource> const& res);
std::size_t compute_hash(gsl::not_null<std::unique_ptr<Resource> const&> res);

    // "will" or "might" reseat pointer
// void reseat(unique_ptr<widget>&);
void reseat(gsl::not_null<unique_ptr<widget>&>);

    // "might" retain refcount
// void may_share(shared_ptr<widget> const&);
void may_share(gsl::not_null<shared_ptr<widget> const&>);

But for now, let's not. Either way, there is really no need for a dedicated type with not_null_2<> semantics.