I don't think observer and observer_ptr are the good names. Both are pointers as they have pointer semantics. I'll suggest not_null_ptr and observer_ptr I consider both to be pointer-like types because they implement `operator*` and have reference (pointer-like) semantics. But `observer` is not default constructible, constructible from `T*` or `nullptr_t`, and is not contextually convertible to `bool`. I chose the name `observer` because it conveys intent (to observe something), and I felt it was appropriate to append `_ptr` to the type that is constructible from a pointer (because thus has a null state). The types are inherently similar, so I feel they should have similar names. I dislike the name `not_null_ptr` because it conveys no intent (there is more than one use for a non-owning pointer to a single object), and because it makes it seem completely unrelated to `observer_ptr`. I'm confused. observed_ptr is part of the C++ Fundamental TS v2. Why do you say that it was rejected? I was informed by the author of the proposal that the committee had made it clear that they were not interested in an "observer" pointer in any form. Perhaps this is not accurate, as someone else on this thread suggested. So you have added the implicit conversion from T& to the FTSV2 observed_ptr. Why implicit? You have added mixed comparisons, between observed_ptr<T1> and T2. Have you added them because the conversion was implicit? Could you show a concrete and real a use case? I added this because I believed it to be reasonable. The reason is that it discourages the use of raw pointer, which is not conceptually type safe and can be error prone. However, after someone pointed out that implicit conversion from `T&` makes the intentions of the function taking an `observer_ptr` unclear, I feel that it might be safer to make the conversion explicit. `make_observer` would be the standard way to construct an `observer`, essentially replacing the `&` operator in this context. Mixed comparisons naturally follow from implicit conversions, but they would be removed if the conversions were made explicit. Wondering if an explicit conversion from T*, requiring that T* is not nullptr is not useful. This is C++. When the user knows that the pointer is not null, it seams natural that the user can construct an observer<T> if (T* ptr = f()) g(observer<T>(ptr)); observer<T>(ptr) will be UB if ptr is equal to nullptr. Or are you suggesting that the user de-reference the pointer to get a reference if (T* ptr = f()) g(observer<T>(*ptr); or with a factory if (T* ptr = f()) g(not_null(ptr); The entire point of `observer` is to avoid making assumptions, and to have the type system enforce preconditions at compile-time. By allowing construction from `T*`, the compile-time type-safety of `observer` is lost. This is one of the major issues I have with `gsl::not_null` (though it has many other problems). And yes, the user has to dereference a pointer to convert it to an `observer`. It is commonly understood that dereferencing a null pointer is UB, and this can be tested for with static analysis tools. There is no need to design more UB into types that are supposed to be more high-level and type-safe than the C-style options (e.g. pointers). I believe it is worth proposing the not-null observer pointer to the C++ standard. And why not the construction from T& for observer_ptr<T>. I have three options for my proposal, all recommended as the best avenue by different people: the C++ standard, Boost, and the GSL. I'm not sure which one to persue. I'm glad you think that the idea is worth proposing though :) I don't share the get_pointer concern. smart pointer have a get function . However I believe it is worth proposing an explicit conversion in addition to the get function `get_pointer` is a relatively minor design detail that isn't fundamental to the proposal. I wouldn't be devastated by a `get` member function. Thanks for taking the time to look at everything in detail!