Address not_null design question

[JordanMaples]

#379 #399 #509 see also #225

Microsoft/GSL not_null has an implicit conversion from T to not_null<T> which doesn't follow the guidelines explicit conversions. However, making it explicit as the guidelines direct causes problems including being too verbose to use.

[hsutter]

Editors' call: This set of issues deserves a new look at whether not_null should be a general type, a type that works only on raw pointers, or an alias. GDR will write a note.

[KVic]

Let me express my humble opinion. I think that the not_null semantics is needed not only for raw pointers but also for smart pointers. And it should be consistent: if it is possible to create a shared_ptr from a unique_ptr, then it should be possible to create a not_null<shared_ptr> from a not_null<unique_ptr> and so on.

I researched this subject more deeply and wrote the C++ Object Token Library. Maybe it will help make decisions about the design of the gsl::not_null.