Quick note: I just subscribed to the list, and perhaps because I had "digest mode" switched on until just now, this was the first reply I received. Are there any other replies I haven't seen? On Wed, Feb 1, 2017 at 6:24 PM, Oswin Krause < Oswin.Krause@ruhr-uni-bochum.de> wrote:

Hi,

Can observer_ptr refer to no object? If not, why not just use T &? If

...

so, why not just use optional<T>?

As far as i understood it, it is still assignable, unlike T&.

`observer_ptr<T>` can be null; `observer<T>` cannot. `T&` is not the same in a number of ways: - `T&` cannot be "rebound" after construction. - `T&` makes containing classes non-copy assignable by default - `T&` cannot be stored in arrays - `T&` cannot be stored in containers (though I saw maybe this is a feature being added to the C++ standard?) - `T&` has value assignment and comparison semantics (they operate on the referenced value); the observer types have reference (pointer-like) assignment and comparison semantics. They behave very differently with algorithms and containers ( `reference_wrapper` has reference assignment semantics, which makes it work properly in containers, but it still has value comparison semantics. Essentially, `T&` (and `reference_wrapper<T>`) is not a pointer type, and has totally different semantics. `observer_ptr` and `observer` have pointer semantics and are useful where pointers would be useful. For me, the biggest problem of the proposal is that observer_ptr<T> is

implicitely constructed from T&. In my code I often use:

Foo a; Bar b(&a);//&a signals that b only references to a, but does not copy it.

Now, when I write

Bar b(a); //so is a now copied?

While the interface is clearer in documentation, the usage is less clear!

I personally have used this pattern in code before without confusion: bar(foo const& f) : m_f(&f) {} Indeed, the documented interface is clearer if you use `observer<foo const>`, but the calling code looks the same. I did anticipate that this might be a problem for some people (though I am personally comfortable with it). If this is a widespread concern, the implicit conversion from `T&` could be removed `make_observer` would become the recommended way to create an `observer`: Bar b(make_observer(a));

On 2017-02-01 12:02, Olaf van der Spek wrote:

On Wed, Feb 1, 2017 at 11:24 AM, Oswin Krause wrote:

...

For me, the biggest problem of the proposal is that observer_ptr<T> is implicitely constructed from T&. In my code I often use:

Foo a; Bar b(&a);//&a signals that b only references to a, but does not copy it.

Now, when I write

Bar b(a); //so is a now copied?

While the interface is clearer in documentation, the usage is less clear!

IMO using pointers instead of references to indicate something isn't copied is bad practice.. the language is C++, not C.

This is not a C vs C++ thing. But assume it was. How would you indicate that in C++? It should be clear without looking at the reference whether it is okay for a to go out of scope before b or not.

On Wed, Feb 1, 2017 at 10:27 AM, Rob Stewart wrote:

On February 1, 2017 2:47:54 AM EST, Joseph Thomson wrote: Can observer_ptr refer to no object? If not, why not just use T &? If so, why not just use optional<T>?

optional<T> is a value, not a pointer/reference.. -- Olaf

On Wed, Feb 1, 2017 at 11:07 PM, Brook Milligan wrote:

...

On Feb 1, 2017, at 12:47 AM, Joseph Thomson wrote:

The `observer_ptr<T>` class template is a pointer-like type that does not do any resource management, and is intended to be used in place of `T*` wherever `T*` is used as a non-owning reference to an object of type `T`. `observer_ptr<T>` has three main advantages over `T*`:

From my own experience, which includes writing my own version of exactly what you are describing and using it extensively in a large code base, I wholeheartedly agree with your sentiment and would welcome a standardized version of this. Just as std::unique_ptr and std::shared_ptr explicitly document their semantics, so too does observer_ptr, therefore making the code clearer to readers, users, and maintainers. Large code bases are always maintained by more than one person, and unless everyone agrees on the meaning of T* there can be confusion, subtle errors, and maintenance problems. The idea of an observer_ptr class avoids that and enables legacy code to be transformed at will.

Exactly. I have heard it suggested that once all other uses are covered by high-level types, the only use case left for `T*` is as a non-owning pointer. Even ignoring the real safety benefits a well-designed "observer" type brings, this idea is flawed because: 1. This is just a convention; no one is forced to follow it. 2. Even if everyone did follow it, legacy code will still use `T*` for other purposes. 3. Even if all legacy code were updated, low level code still uses `T*` for other purposes. If it would be helpful, I would be happy to contribute anything from my own

incarnation of an observer_ptr. Perhaps merging ideas would ensure that the API handles use cases well.

While I was just floating the idea and a review process has not officially started, I would be happy to hear any ideas you have. Have you seen my implementation that I linked to in my OP? Something that you did not mention that I have found useful is a

make_observer() function for construction. This is mostly useful to explicitly construct an observer when that helps code clarity.

My messages are moderated as I am a new subscriber to the list, so they may not have gone through yet, but I have mentioned that I have a `make_observer` function. If people feel that implicit conversion from `T&` is bad, it could even be the primary way to construct an `observer`. Given the increased clarity and decreased ambiguity I have seen in my code

when using this (isn’t that ultimately the goal of the STL and other designed libraries?), I have always wondered about the antipathy this idea faces, so I hope your proposal makes better progress.

Indeed. I was surprised when I found out the C++ standards committee was so hostile to the idea. I'm glad that people seem receptive to the idea here.

There is already an observer_ptr proposed for c++17. http://en.cppreference.com/w/cpp/experimental/observer_ptr On 1 February 2017 at 17:22, Edward Diener wrote:

On 1/31/2017 11:47 PM, Joseph Thomson wrote:

...

For some time, I have been developing a pair of non-owning pointer-like types that I am currently calling `observer_ptr` and `observer`. I had planned to propose their addition to the C++ standard library, but I have been informed by the author of the original `observer_ptr` proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf that the ISO C++ committee has rejected his proposal and made clear that it feels there is no place in the standard library for such types, believing that this role is filled to a satisfactory degree by regular pointers. I wholeheartedly disagree with this assessment, so I am bringing my proposal here instead.

The `observer_ptr<T>` class template is a pointer-like type that does not do any resource management, and is intended to be used in place of `T*` wherever `T*` is used as a non-owning reference to an object of type `T`.

When referring to 'T*' I think you should always use the terminology 'pointer' rather than 'reference'. By mixing the two you are confusing terminology, which I believe should always be distinct because a pointer and a reference are syntactically two different things in C++.

snipped...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

On Thu, Feb 2, 2017 at 6:18 AM, Niall Douglas wrote:

...

...

For some time, I have been developing a pair of non-owning pointer-like types that I am currently calling `observer_ptr` and `observer`. I had planned to propose their addition to the C++ standard library, but I have been informed by the author of the original `observer_ptr` proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf that the ISO C++ committee has rejected his proposal and made clear that it feels there is no place in the standard library for such types, believing that this role is filled to a satisfactory degree by regular pointers. I wholeheartedly disagree with this assessment, so I am bringing my

...

here instead. I don't think that exactly accurate. Rather it is that the GSL's

On 01/02/2017 07:47, Joseph Thomson wrote: proposal proposed schema of:

* owner<T> is an owning pointer * span<T> is a borrowed pointer/reference/view * C type pointers are non-owning, non-borrowed

As far as I understand it, `span<T>` is a view of objects over a range, in the vein of `array_view<T>`, and raw pointers are simply non-owning. I'm not sure what "borrowed" means in this context.

... has general wide agreement in principle, if not in exact

...

formulation. The Library Fundamentals TS v2 does have an observer_ptr in std::experimental, but there is general lack of sureness as to what it actually contributes when a non-annotated pointer according to the GSL schema is either an observer by definition, or unupgraded code.

That is just one of the benefits I listed (documentation of intent). The most benefit important IMO is *type-safety*, followed closely by a more minimal interface. The `observer_ptr<T>` in `std::experimental` only has type safety in one direction (conversion to `T*` is explicit), because the only way to construct it is from `T*`. Observers should preferably be constructed from `T&`, as this is a type-safe conversion. The `observer_ptr<T>` in `std::experimental` needs one change to make it type safe: change `make_observer(T*)` to `make_observer(T&)`. We need a proposal to change experimental::observer_ptr :)

In my opinion, designating `T*` to mean "observer" would be okay in an ideal world (it still has far too general an interface for something that just observes), but the world isn't ideal. Not everyone reads the GSL guidelines, and those who do won't follow it to the letter, and even if they did there is still plenty of "unupgraded" code. Also, I think you too easily dismiss the benefit of being able to distinguish between un-upgraded and upgraded code; this sounds very useful if you ask me. So, to reiterate again, `observer_ptr`:

- Allows upgraded code to be distinguished from un-upgraded code (this is more important than you might think) - Removes operations that are inappropriate for an observer type (pointer arithmetic, array subscript, conversion to `void*`) - Provides type safety by allowing construction from `T&` and disallowing construction from and conversion to `T*` I agree we need this vocabulary type. GSL guidelines are for code that will be written from scratch with C++14/C++17. The reality is that we have tons of C++98 code. Pretending that T* is a not owning pointer because we have gsl::owner is not useful in a legacy code project. I'm not saying that gsl::owner is not useful. Whether to allow implicit/explicit conversion from `T&` is a design detail. The benefits are there regardless. Yes, I believe the implicit conversion could be questionable.

Also, it seems to me that the natural meaning of `T*` in C++ is as an iterator, not an observer:

int arr[] = { 1, 2, 3 }; auto it = std::end(arr); // `decltype(it)` is `int*`

I'd need a fair bit of convincing that observer<T> has merit in any form

...

except additional clarity to help demarcate unupgraded code from upgraded code. If that's your argument, and you're not doing funny things with implicit conversion from T& and other funny non-GSL semantics, I'd suppose this though I'd suggest you actually contribute it to GSL itself and persuade Neil to let it in.

`observer<T>` is similar to `not_null<T>`, in that it enforces a "not null" precondition, except `observer<T>` does a much better job because it enforces the precondition at compile-time.

auto o = make_observer(null_ptr); // compile error: expects `T&` auto n = not_null(null_ptr); // compiles fine; run-time error I prefer also a not null smart pointer that takes this as a

Le 02/02/2017 à 02:15, Joseph Thomson a écrit : precondition. Requiring the class to check the parameter is not nullptr (as gsl::not_null does) is more than what I need.

`observer` forces the user to dereference their pointer, which should be flagged as unsafe by the static analyser if they don't check for null. `not_null` waits until compile-time to report the error, and makes it harder for a static analyser to catch the potential null pointer bug.

I have had a few discussions with Neil over at the GSL GitHub page about the purpose of `not_null`. Honestly, the design goals of `not_null<T>` seem unclear to me; it seems to be trying to do too many things at once, simultaneously trying to be a drop-in replacement for `T*` that enforces a "not null" precondition at run-time (it's meant to be able to hold any kind of pointer or pointer-like object), but also trying to be this high-level modern type that has compile-time type safety (it deletes various pointer arithmetic operations, and it has been seriously suggested that conversion from `T` should be explicit). It was initially meant to be compatible with smart pointers like `unique_ptr`, but this goal seems to have been all but abandoned after it was realised that this won't really work. It's also meant to be used in conjunction with strings, despite the fact that `string_view` is a much better alternative, and with the `owner` annotation, despite the fact that this will probably have the same conceptual problems as `unique_ptr`. If my ramblings sound confused, it's because I am confused, because `not_null` is confused. Maybe we could have not_null<Ptr> that works for any pointer-like type, but what I need today is not_null_ptr<T>. Maybe it is worth providing a single not_null instantiation.

The GSL is a *much* better home for it than Boost because then you'll

...

have Bjarne batting for it, plus static checking support from Microsoft in VS2017 and Google via clang-tidy. You'll also get a *huge* userbase almost instantly, because the GSL or rather one of its C++ 98 clones is seeing exponential growth recently. It's amazingly useful for upgrading ancient C++ codebases.

This would be good. If I brought this to the GSL, I would pretty much be proposing that `not_null` is scrapped in favour of `observer` and `observer_ptr`. `not_null<zstring>` is obsoleted by `string_view`; `not_null` etc. are broken; `not_null` is of little value IMO, and may be conceptually broken too; honestly, the only useful case is `not_null`, and that currently has big issues with its design too. `observer` and `observer_ptr` are essentially `maybe_null` and `not_null` with clearer design goals and a fixed interface.

In reverse order ;-) Vicente

I agree we need this vocabulary type. GSL guidelines are for code that will be written from scratch with C++14/C++17. The reality is that we have tons of C++98 code. Pretending that T* is a not owning pointer because we have gsl::owner is not useful in a legacy code project. I'm not saying that gsl::owner is not useful. Sorry, one additional comment. AFAIK, the GSL is aimed at those writing new C++ code, those updating old C++ code, and those making low-level C++ code safer. For example, `owner` is for use where something like `unique_ptr` cannot be used (either legacy code, or perhaps the library implementation of `unique_ptr` itself!)

On Fri, Feb 3, 2017 at 1:17 PM, David Stone wrote:

There is only one proper way to represent the concept of a T that might not be a T: optional<T>, so I think you are defining your objects backward. The "top level" type should be observer<T>, and if you want to support the concept of nullness, use optional. This is a much more consistent way to treat nullness throughout the language, rather than special-casing it for every type.

I actually agree with you from an ideological perspective, but practical implications drove me to my current design. My original goal was to create a better interface for `not_null`, where the "not null" precondition was enforced at compile-time. I came up with `observer<T>` and deligated `optional` as the optional counterpart. However, I realised that `optional` is not a zero-overhead abstraction: it is twice the size of `T*` and many of its operations do more than just reading and writing a pointer. I worried that this would hurt adoption, so I created a zero-overhead replacement called `optional_observer<T>`. Originally, I was using `nullopt` to make `optional_observer<T>` look like `optional<T>`, but soon realised that it was impossible to get both zero-overhead comparison operations *and* have behavour consistent with `optional<T>` (essentially, `nullopt` compares lower than any `T`, but the ordering of `nullptr_t` is implementation-specified). Thus, I replaced it with my own `nullobs` constant before realising it was just duplicating the function of `nullptr` (`optional_observer<T>` was constructible from `T*` and `nullptr_t` for performance and convenience reasons), so I removed `nullobs` and ended up with something that looked very much like `observer_ptr<T>`, so I renamed it and here we are today. And `observer<T>` is still the "top level" type in a sense. `make_observer` returns an `observer<T>`, and `observer_ptr<T>` is implicitly convertible from `observer<T>`. This is another thing that is wrong with `not_null`: it gets things backwards by putting the nullable type (`T*`) on top and trying to suppress that nullability with a wrapper. This is why it ends enforcing the "not null" precondition at run-time instead of compile-time, because `not_null<T>` has to be constructed from `T`, a nullable type.

On Sat, Feb 4, 2017 at 2:59 PM, David Stone wrote:

Using optional does not imply any overhead. You simply provide a specialization for optional. You make optional a friend of observer<T>, and create a private constructor that acts as the back door to allow your type to store a nullptr inside it to represent the empty state. Then the only way to get in this state is through optional, so users of the type never see that such a state is possible.

This is quite true. I did consider this, but for some reason dismissed it. But I guess this optimization would be allowable under the as-if rule http://en.cppreference.com/w/cpp/language/as_if? Of course, this is contingent on `observer<T>` becoming part of the C++ standard.

The behavior of operator< is a little trickier. That being said, I do not believe that this type should have operator<. This type is not usable as an iterator, which is the only situation where operator< makes sense for pointer types. Instead, I would just specialize std::less (which I see you delegate to in your operator<) to allow use in std::map. Then the question of the performance of optional's operator< goes away, because it is not defined.

Sounds reasonable. I only defined the operators to allow storage in ordered associative containers, but you are right that this only requires a specialization of `less`. I have a minor gripe with `optional` because you end up having to double dereference to access the underlying object: optional ooi = some_int; **ooi = 42; That said, I am also slightly annoyed at the fact that, after removing implicit conversion from `T&`, there is no neat way to convert an `observer_ptr<T>` to an `observer<T>`. With `optional`, this is not a problem (because of the double dereferencing): optional ooi = some_int; observer<int> oi = *ooi; int i = **ooi; However, I have come to appreciate that syntactic brevity is not always a sign of correct design, and syntax is rarely a compelling justification for a design decision. In this case I believe the double dereference may be warranted. Thanks for your input. It is very useful!

On Thu, Feb 2, 2017 at 6:18 AM, Niall Douglas wrote:

I'd need a fair bit of convincing that observer<T> has merit in any form except additional clarity to help demarcate unupgraded code from upgraded code. If that's your argument, and you're not doing funny things with implicit conversion from T& and other funny non-GSL semantics, I'd suppose this though I'd suggest you actually contribute it to GSL itself and persuade Neil to let it in.

The GSL is a *much* better home for it than Boost because then you'll have Bjarne batting for it, plus static checking support from Microsoft in VS2017 and Google via clang-tidy. You'll also get a *huge* userbase almost instantly, because the GSL or rather one of its C++ 98 clones is seeing exponential growth recently. It's amazingly useful for upgrading ancient C++ codebases.

I have just written up a proposal for inclusion of these types in the GSL, which you can find here: https://github.com/hpesoj/cpp-observer/blob/master/GSL-PROPOSAL.md While I don't want to appropriate the Boost mailing list for unrelated purposes, I thought I would post this here since I am still not entirely sure where I should be proposing this. My proposal would pretty much look the same whoever I pitched it to. And perhaps those involved in this thread are interested anyway. I'd be glad to hear any opinions. p.s. I am no longer doing funny things with implicit conversion from `T&`.

Naming: - I think pointer or reference like things should be named _ptr or _ref etc. (In comparison, optional and any can be null, but own their value, they don't reference an external value.) - 'observer' has already been taken by the Gang of Four as a design pattern. Unfortunately. We could re-take the term, but it does add confusion. - I've suggested cadged_ptr in the past - it is not a great word, as it it not very common, but it is actually the right meaning. And by not being common, it means we can imbue it with whatever meaning we'd like. In that sense it is a perfectly cromulent word. Tony On Thu, Feb 9, 2017 at 8:08 AM, Joseph Thomson via Boost wrote:

On Thu, Feb 2, 2017 at 6:18 AM, Niall Douglas wrote:

...

The GSL is a *much* better home for it than Boost because then you'll have Bjarne batting for it, plus static checking support from Microsoft in VS2017 and Google via clang-tidy. You'll also get a *huge* userbase almost instantly, because the GSL or rather one of its C++ 98 clones is seeing exponential growth recently. It's amazingly useful for upgrading ancient C++ codebases.

For those who are interested, I have included `observer<T>` (but not `observer_ptr<T>`) as part of a proposal regarding the recommended use of pointers over at the C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines. If you feel so inclined, you can continue the discussion in the issue I created. I have taken on board some of the feedback I received in this thread, so thanks very much.

Issue: https://github.com/isocpp/CppCoreGuidelines/issues/847 Proposal: https://github.com/hpesoj/gsl-pointers

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 2/9/2017 1:56 PM, Gottlob Frege via Boost wrote:

Naming:

- I think pointer or reference like things should be named _ptr or _ref etc. (In comparison, optional and any can be null, but own their value, they don't reference an external value.)

I agree that adding _ptr to something that takes the form of a pointer is a good idea.

- 'observer' has already been taken by the Gang of Four as a design pattern. Unfortunately. We could re-take the term, but it does add confusion.

I see no confusion using a term which has been mentioned as a design pattern.

- I've suggested cadged_ptr in the past - it is not a great word, as it it not very common, but it is actually the right meaning.

I do not think it is necessary to use a fairly obscure word as opposed to a more common term, unless that common term is misleading.

And by not being common, it means we can imbue it with whatever meaning we'd like. In that sense it is a perfectly cromulent word.

Tony

On Thu, Feb 9, 2017 at 8:08 AM, Joseph Thomson via Boost wrote:

...

On Thu, Feb 2, 2017 at 6:18 AM, Niall Douglas wrote:

...

The GSL is a *much* better home for it than Boost because then you'll have Bjarne batting for it, plus static checking support from Microsoft in VS2017 and Google via clang-tidy. You'll also get a *huge* userbase almost instantly, because the GSL or rather one of its C++ 98 clones is seeing exponential growth recently. It's amazingly useful for upgrading ancient C++ codebases.

For those who are interested, I have included `observer<T>` (but not `observer_ptr<T>`) as part of a proposal regarding the recommended use of pointers over at the C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines. If you feel so inclined, you can continue the discussion in the issue I created. I have taken on board some of the feedback I received in this thread, so thanks very much.

Issue: https://github.com/isocpp/CppCoreGuidelines/issues/847 Proposal: https://github.com/hpesoj/gsl-pointers

On 10/02/2017 12:24, Joseph Thomson via Boost wrote:

I initially read that as `caged_ptr`. I looked up the definition, and it does seem to have the right meaning. If such an uncommon word is undesirable, perhaps `obseved_ptr` or `watched_ptr` would be preferable (the "-ed" form of the veb matches `shared_ptr`).

At the risk of devolving into a bikeshed, I don't really like anything that implies observing or watching unless it has the semantics of weak_ptr and knows when it is no longer pointing to a valid object. How about borrowed_ptr, unbound_ptr, irresponsible_ptr, unowned_ptr, or not_null_ptr? (Though a shorter typedef probably should be encouraged in practice or people would likely just stick with *.)

On Fri, Feb 10, 2017 at 3:12 AM, Joseph Thomson via Boost wrote:

On Fri, Feb 10, 2017 at 7:59 AM, Gavin Lambert via Boost < boost@lists.boost.org> wrote:

...

On 10/02/2017 12:24, Joseph Thomson via Boost wrote:

...

I initially read that as `caged_ptr`. I looked up the definition, and it does seem to have the right meaning. If such an uncommon word is undesirable, perhaps `obseved_ptr` or `watched_ptr` would be preferable (the "-ed" form of the veb matches `shared_ptr`).

At the risk of devolving into a bikeshed, I don't really like anything that implies observing or watching unless it has the semantics of weak_ptr and knows when it is no longer pointing to a valid object.

How about borrowed_ptr, unbound_ptr, irresponsible_ptr, unowned_ptr, or not_null_ptr? (Though a shorter typedef probably should be encouraged in practice or people would likely just stick with *.)

A previous name I used was `indirect`, to give it an air of pointer-ness without using the terms "pointer" or "reference" (though it doesn't have a `_ptr` suffix). If we're being creative, the name could emphasise how the pointee is liable to die before the pointer itself.

volatile_ptr

volatile int * ptr; // a volatile pointer Rule 5 about naming - avoid "spoken ambiguity" - If I say to another dev "you need to use a volatile pointer here" did I mean volatile_ptr or volatile Foo * ?

transient_ptr

I kinda like that one.

mercurial_ptr unsafe_ptr unstable_ptr

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Mon, Feb 13, 2017 at 10:15 PM, Josh Juran via Boost wrote:

On Feb 9, 2017, at 6:59 PM, Gavin Lambert via Boost wrote:

...

How about borrowed_ptr, unbound_ptr, irresponsible_ptr, unowned_ptr, or not_null_ptr? (Though a shorter typedef probably should be encouraged in practice or people would likely just stick with *.)

Consider nonnull_ptr in place of not_null_ptr.

Josh

notmy_ptr is another of my favourites :-)

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!