Re: [boost] Is there any interest in non-owning pointer-like types?

Subject: Re: [boost] Is there any interest in non-owning pointer-like types?
From: Joseph Thomson (joseph.thomson_at_[hidden])
Date: 2017-02-03 02:55:22

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!