[std-proposals] shared_ptr and unique_ptr should both implicitly convert to observer_ptr

[m***@gmail.com]

Hello, consider the following point of view

std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)

To write an interface that accepts strings (pre C++17) it is acceptable to
write

void f(const char*);
void f(const std::string&);

To write an interface that accepts T it is acceptable to write

void f(const T*);
void f(const T&);

It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.

There are two problems here,
- first we give advice that contradicts the string example (the interface
is depend on how the string is stored)
- second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.

Enter C++17

The string situation is *further *improved

void f(std::string_view);

We can do what we preach and have an interface that does not depend on how
the string is stored while at the same time keep the interface transparent
on the call site.

The situation with objects is unchanged.

But does it have to be that way? Why not have

void f(observer_ptr<const X>);

*instead of *

void f(const T*);

*AND*

let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>

This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C) observing
form.

In both raw storage is explicit call, however observing is implicit
conversion.

Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management

void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }

auto c = std::make_unique<C>();

friendly(c); //< happy, transparent usage

evil(c); //< nope

auto p = observer_ptr(c);

evil(p); //< nope


We will hit multiple birds
- Have consistency with other std objects that do or will use a view form
- Give perfect alternative for writing interfaces that take managing smart
pointers only to use the managed object
- Find observer_ptr a meaning for existence, way and beyond "documenting
usage".

Thoughts? Any downsides I missed?

[Richard Hodges]

Any object that can be represented in a function call interface as
observer_ptr<T> can be equally correctly represented as T&.

Why wouldn't I just write my interfaces in terms of references? Wouldn't
that give me more flexibility? consider:

#include <optional>
#include <memory>

struct Foo
{
};

void foo_thing(Foo& f)
{
}

void test()
{
auto a = std::optional<Foo>({});
auto b = std::make_unique<Foo>();
auto c = std::make_shared<Foo>();

foo_thing(*a);
foo_thing(*b);
foo_thing(*c);
}

If I wanted to take copies of that reference, std::reference_wrapper<Foo>
would also be an acceptable argument type.

Post by m***@gmail.com
Hello, consider the following point of view
std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
To write an interface that accepts strings (pre C++17) it is acceptable to
write
void f(const char*);
void f(const std::string&);
To write an interface that accepts T it is acceptable to write
void f(const T*);
void f(const T&);
It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.
There are two problems here,
- first we give advice that contradicts the string example (the interface
is depend on how the string is stored)
- second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.
Enter C++17
The string situation is *further *improved
void f(std::string_view);
We can do what we preach and have an interface that does not depend on how
the string is stored while at the same time keep the interface transparent
on the call site.
The situation with objects is unchanged.
But does it have to be that way? Why not have
void f(observer_ptr<const X>);
*instead of *
void f(const T*);
*AND*
let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C)
observing form.
In both raw storage is explicit call, however observing is implicit
conversion.
Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management
void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }
auto c = std::make_unique<C>();
friendly(c); //< happy, transparent usage
evil(c); //< nope
auto p = observer_ptr(c);
evil(p); //< nope
We will hit multiple birds
- Have consistency with other std objects that do or will use a view form
- Give perfect alternative for writing interfaces that take managing
smart pointers only to use the managed object
- Find observer_ptr a meaning for existence, way and beyond "documenting
usage".
Thoughts? Any downsides I missed?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org?utm_medium=email&utm_source=footer>
.

[m***@gmail.com]

Post by Richard Hodges
Any object that can be represented in a function call interface as
observer_ptr<T> can be equally correctly represented as T&.

Unless you want it to be nullable, in which case I think you need to do
something like std::optional<std::reference_wrapper<Foo>>.

Related: I really wish std::optional<T&> was allowed.

[Richard Hodges]

Post by Richard Hodges
Any object that can be represented in a function call interface as

Post by Richard Hodges
observer_ptr<T> can be equally correctly represented as T&.

Unless you want it to be nullable, in which case I think you need to do
something like std::optional<std::reference_wrapper<Foo>>.

I thought we had moved on from testing raw pointers for null 20 years ago?
Don't we write in terms of *semantic intent* these days? The use of
pointers implies addresses, which implies memory, and as we know, the idea
of objects actually existing as bit patterns in memory is considered a
thought crime. (am I joking? Sometimes when addressing people in this forum
I'm not sure...)

Post by Richard Hodges
Related: I really wish std::optional<T&> was allowed.

The committee failed the user base horribly when it decreed that it would
not adopt optional<T&>. It was an insane decision, which ought to be simple
to reverse.

After all, the most logical implementation of optional<T&> is a trivial
wrapper around a pointer.

Post by Richard Hodges
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb06dfa7-74f0-4986-9cd1-3f85c395541a%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Nevin Liber]

Post by m***@gmail.com
Related: I really wish std::optional<T&> was allowed.
The committee failed the user base horribly when it decreed that it would
not adopt optional<T&>. It was an insane decision, which ought to be simple
to reverse.

The committee never decreed such a thing. What actually happened:
https://stackoverflow.com/questions/26858034/stdoptional-specialization-for-reference-types/26895581#26895581

After all, the most logical implementation of optional<T&> is a trivial

Post by m***@gmail.com
wrapper around a pointer.

That is not a description of what the *interface* should be.

[m***@gmail.com]

Post by Richard Hodges
Any object that can be represented in a function call interface as
observer_ptr<T> can be equally correctly represented as T&.

As others pointed out - the difference is that observer_ptr can be null.

Ultimately one can have

void foo_thing(const Foo& f) {}
void foo_thing(observer_ptr<const Foo> f) { if(f) foo_thing(*f); }

And the clients will be beyond happy - completely transparent interface -
not get(), not operator* and works with stack variables.
And *no reason *to write foo_thing(const unique_ptr<const Foo>& f)


*That said*, you make a very interesting point - what about optional?

If our philosophy is - use the object without know knowing or caring how it
is stored, then it makes sense optional also to convert to observer_ptr

After all, optional is just a stack storage (in which an object might or
might not been stored).

This would allow us to exhaust all options.

void test()
{
auto a = Foo{};
auto b = std::make_unique<Foo>();
auto c = std::make_shared<Foo>();
auto d = std::optional<Foo>({});


foo_thing(a); //< transparent access as in Java, old C++ and what not
foo_thing(b); //
foo_thing(c); //
foo_thing(d); //
}


SIDEQUESTION: Why does observer_ptr have an explicit constructor? What is
guarding against?
After all it is the more constrained type (then raw pointer) and there is
the "is da thing" relationship.

I am asking because of

void f(observer_ptr<C>);

C c;
f(&c); //< not working, which is annoying as all hell and feels wrong

Post by Richard Hodges
Why wouldn't I just write my interfaces in terms of references? Wouldn't
#include <optional>
#include <memory>
struct Foo
{
};
void foo_thing(Foo& f)
{
}
void test()
{
auto a = std::optional<Foo>({});
auto b = std::make_unique<Foo>();
auto c = std::make_shared<Foo>();
foo_thing(*a);
foo_thing(*b);
foo_thing(*c);
}
If I wanted to take copies of that reference, std::reference_wrapper<Foo>
would also be an acceptable argument type.

Post by m***@gmail.com
Hello, consider the following point of view
std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
To write an interface that accepts strings (pre C++17) it is acceptable
to write
void f(const char*);
void f(const std::string&);
To write an interface that accepts T it is acceptable to write
void f(const T*);
void f(const T&);
It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.
There are two problems here,
- first we give advice that contradicts the string example (the
interface is depend on how the string is stored)
- second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.
Enter C++17
The string situation is *further *improved
void f(std::string_view);
We can do what we preach and have an interface that does not depend on
how the string is stored while at the same time keep the interface
transparent on the call site.
The situation with objects is unchanged.
But does it have to be that way? Why not have
void f(observer_ptr<const X>);
*instead of *
void f(const T*);
*AND*
let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C)
observing form.
In both raw storage is explicit call, however observing is implicit
conversion.
Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management
void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }
auto c = std::make_unique<C>();
friendly(c); //< happy, transparent usage
evil(c); //< nope
auto p = observer_ptr(c);
evil(p); //< nope
We will hit multiple birds
- Have consistency with other std objects that do or will use a view form
- Give perfect alternative for writing interfaces that take managing
smart pointers only to use the managed object
- Find observer_ptr a meaning for existence, way and beyond "documenting
usage".
Thoughts? Any downsides I missed?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/81a04b52-e5cd-4543-86c5-5a0068f9647b%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Tony V E]

Post by m***@gmail.com
Hello, consider the following point of view
std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
To write an interface that accepts strings (pre C++17) it is acceptable to
write
void f(const char*);
void f(const std::string&);
To write an interface that accepts T it is acceptable to write
void f(const T*);
void f(const T&);
It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.
There are two problems here,
- first we give advice that contradicts the string example (the interface
is depend on how the string is stored)
- second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.
Enter C++17
The string situation is *further *improved
void f(std::string_view);
We can do what we preach and have an interface that does not depend on how
the string is stored while at the same time keep the interface transparent
on the call site.
The situation with objects is unchanged.
But does it have to be that way? Why not have
void f(observer_ptr<const X>);
*instead of *
void f(const T*);
*AND*
let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C)
observing form.
In both raw storage is explicit call, however observing is implicit
conversion.
Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management
void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }
auto c = std::make_unique<C>();
friendly(c); //< happy, transparent usage
evil(c); //< nope
auto p = observer_ptr(c);
evil(p); //< nope
We will hit multiple birds
- Have consistency with other std objects that do or will use a view form
- Give perfect alternative for writing interfaces that take managing
smart pointers only to use the managed object
- Find observer_ptr a meaning for existence, way and beyond "documenting
usage".
Thoughts? Any downsides I missed?

I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.

Only question: observer_ptr is a terrible name, what should we call it.

[Brian Bi]

Post by Tony V E

Post by m***@gmail.com
Hello, consider the following point of view
std::string is to char*, what is std::unique_ptr<T> to T* (minus copying)
To write an interface that accepts strings (pre C++17) it is acceptable
to write
void f(const char*);
void f(const std::string&);
To write an interface that accepts T it is acceptable to write
void f(const T*);
void f(const T&);
It is NOT acceptable to write void f(const std::unique_ptr<T>&); as the
interface becomes dependent on how the object is stored.
There are two problems here,
- first we give advice that contradicts the string example (the
interface is depend on how the string is stored)
- second writing a void f(const std::unique_ptr<T>&); *actually buys
something*, it buys us transparent interface - that is why people do it!.
Enter C++17
The string situation is *further *improved
void f(std::string_view);
We can do what we preach and have an interface that does not depend on
how the string is stored while at the same time keep the interface
transparent on the call site.
The situation with objects is unchanged.
But does it have to be that way? Why not have
void f(observer_ptr<const X>);
*instead of *
void f(const T*);
*AND*
let std::unique_ptr<X> *implicitly *convert to observer_ptr<X>
This will closely match the behavior of std::string -
Both will now have A) raw storage form B) managed storage form C)
observing form.
In both raw storage is explicit call, however observing is implicit
conversion.
Because observer_ptr does not convert to raw pointer, it will be safe to
use even with old APIs that might do manual lifetime management
void friendly(observer_ptr<C> c) { if(c) std::cout<<*c<<'\n'; }
void evil(C* c){ delete c; }
auto c = std::make_unique<C>();
friendly(c); //< happy, transparent usage
evil(c); //< nope
auto p = observer_ptr(c);
evil(p); //< nope
We will hit multiple birds
- Have consistency with other std objects that do or will use a view form
- Give perfect alternative for writing interfaces that take managing
smart pointers only to use the managed object
- Find observer_ptr a meaning for existence, way and beyond "documenting
usage".
Thoughts? Any downsides I missed?

I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.
Only question: observer_ptr is a terrible name, what should we call it.

I feel like I've come around to the name observer_ptr, and we should
probably just put it in and the rest of the community will get used to it
too :P

Post by Tony V E
--
Be seeing you,
Tony
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuqHGogymYhCxDGmQWVPegmZQjoOy738k9Ey6J%3DarCe7A%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

[Ville Voutilainen]

I agree with all of this, and, to me, it makes observer_ptr worth standardizing.

You said that before, but the paper didn't materialize. :P

[Tony V E]

On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <

Post by Tony V E

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth

standardizing.
You said that before, but the paper didn't materialize. :P

... yet.

Hopefully next meeting.

[Ville Voutilainen]

Post by Tony V E

Post by Ville Voutilainen

I agree with all of this, and, to me, it makes observer_ptr worth standardizing.

You said that before, but the paper didn't materialize. :P

... yet.
Hopefully next meeting.

Alright; give me the gist of the changes you have in mind, and if you
can, any drafts of the paper and I'll give you
a regtested proper stdlib implementation that has passed the tests of
observer_ptr, modulo changes needed for the changes
we need to make.

[Tony V E]

On Thu, Oct 25, 2018 at 12:21 PM Ville Voutilainen <

Post by Tony V E

Post by Tony V E
On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <

Post by Ville Voutilainen

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth

standardizing.

Post by Tony V E

Post by Ville Voutilainen
You said that before, but the paper didn't materialize. :P

... yet.
Hopefully next meeting.

Alright; give me the gist of the changes you have in mind, and if you
can, any drafts of the paper and I'll give you
a regtested proper stdlib implementation that has passed the tests of
observer_ptr, modulo changes needed for the changes
we need to make.

Cool, thanks. Here's what I've got so far:
https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
I'm not sure it is worth making coding changes yet. Up to you of course.

Now that I think of it, the implicit conversions should probably be on
shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
(ie observer_ptr is the simpler class, it shouldn't depend on
shared/unique, they should depend on it)

Alternatively observer_ptr could have implicit conversion from anything
that "looks like" a smart pointer? Not sure how "looks like" would be
safely defined.

Post by Tony V E
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
.

[Ville Voutilainen]

Cool, thanks. Here's what I've got so far: https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
I'm not sure it is worth making coding changes yet. Up to you of course.
Now that I think of it, the implicit conversions should probably be on shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
(ie observer_ptr is the simpler class, it shouldn't depend on shared/unique, they should depend on it)

If that's the rationale, then I don't think so - this proposal will
probably fare better the less it impacts the rest of the standard,
despite our newly-improved rationale for those conversions.

Alternatively observer_ptr could have implicit conversion from anything that "looks like" a smart pointer? Not sure how "looks like" would be safely defined.

Has a dereference-operator and supports the other operations that
observer_ptr will use?

[m***@gmail.com]

Post by Tony V E

Post by Tony V E

Post by Tony V E
On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <

Post by Ville Voutilainen

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth

standardizing.

Post by Tony V E

Post by Ville Voutilainen
You said that before, but the paper didn't materialize. :P

... yet.
Hopefully next meeting.

Alright; give me the gist of the changes you have in mind, and if you
can, any drafts of the paper and I'll give you
a regtested proper stdlib implementation that has passed the tests of
observer_ptr, modulo changes needed for the changes
we need to make.

https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
I'm not sure it is worth making coding changes yet. Up to you of course.
Now that I think of it, the implicit conversions should probably be on
shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
(ie observer_ptr is the simpler class, it shouldn't depend on
shared/unique, they should depend on it)
Alternatively observer_ptr could have implicit conversion from anything
that "looks like" a smart pointer? Not sure how "looks like" would be
safely defined.

As I said in my previous post - I am not sure any "ptr" is a good idea and
something people will be happy with.

For example will people reach for it when they want to have a reference to
a member, but the object itself might be in empty state?

Sure if they return a const ref and if the object is empty, they can return
a ref to a static empty object, but what about non-const ref?
The jump from a ref to a pointer is a big one and from a const ref to some
library pointer - even more so.

Compare that to optional<X&> - *anyone *will think of it first, *despite *it
has the same interface as pointer.

My point is - we should not let a room for optional<X&> if we have
observer_ptr as it is becoming ridiculous:
- People will swear in "use raw pointer! In modern C++ raw is left for
that purpose"
- People will swear in "use observer_ptr, it is designed for that, don't
listen to raw advocates - you can still delete it and has nasty pointer
arithmetics and what not! Abandon!"
- People will swear in "I want ma optional<X&>! I want to deal with
objects, and references are for that! I want generic code with optional to
Just Work, don't want to switch type"

In any case, I believe there is no doubt that:
- observer_ptr was *never *requested (as it is trivial to implement if one
wants it, *and by no mean all people want it*)
- optional<X&> *is requested every single time one talks about optional*.
Like, seriously, no exaggeration.

If we move with observer_ptr we *must *reject optional<X&> first.

I am OK either way, but the decision must be weighted extremely carefully,
based on use cases and people needs and expectations.

For instance I doubt anyone can anticipate optional to turn into a pointer.
It is simply unexpected, learnable, but unexpected.
Where the reverse is not true - a pointer to turn into "an object that
might not be there" - this is completely expected,

mainly because people already see references as "the object" (and
rightfully so) and "might not there" is already established clearly by
optional itself.

Post by Tony V E

Post by Tony V E
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
.

--
Be seeing you,
Tony

[Ville Voutilainen]

- observer_ptr was never requested (as it is trivial to implement if one wants it, and by no mean all people want it)

It appeared out of thin air? It was approved into the TS even though
nobody wants it?

If we move with observer_ptr we must reject optional<X&> first.
I am OK either way, but the decision must be weighted extremely carefully, based on use cases and people needs and expectations.
For instance I doubt anyone can anticipate optional to turn into a pointer. It is simply unexpected, learnable, but unexpected.
Where the reverse is not true - a pointer to turn into "an object that might not be there" - this is completely expected,
mainly because people already see references as "the object" (and rightfully so) and "might not there" is already established clearly by optional itself.

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

[m***@gmail.com]

- observer_ptr was never requested (as it is trivial to implement if

one wants it, and by no mean all people want it)
It appeared out of thin air? It was approved into the TS even though
nobody wants it?

People requesting it? I have seen many people agreeing there is need for
such a thing, but have not seen requests for it, like real wishlist and
request "please, do this already".
I haven't said noone needs it, Just that people are not requesting it.
I have also seen plenty of *hate *against it though, and plenty request for
option reference.

If we move with observer_ptr we must reject optional<X&> first.
I am OK either way, but the decision must be weighted extremely

carefully, based on use cases and people needs and expectations.

For instance I doubt anyone can anticipate optional to turn into a

pointer. It is simply unexpected, learnable, but unexpected.

Where the reverse is not true - a pointer to turn into "an object that

might not be there" - this is completely expected,

mainly because people already see references as "the object" (and

rightfully so) and "might not there" is already established clearly by
optional itself.
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

Fair enough, question is do we need both?

If we have both, will optional convert to optional ref and pointers to
observer pointer?

If we don't have both, do we like the pointer model or the "has-a model"
(even with the looser definition of "has") to represent objects?

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 7:34 PM Ville Voutilainen

Post by Ville Voutilainen

- observer_ptr was never requested (as it is trivial to implement if one wants it, and by no mean all people want it)

It appeared out of thin air? It was approved into the TS even though
nobody wants it?

If we move with observer_ptr we must reject optional<X&> first.
I am OK either way, but the decision must be weighted extremely carefully, based on use cases and people needs and expectations.
For instance I doubt anyone can anticipate optional to turn into a pointer. It is simply unexpected, learnable, but unexpected.
Where the reverse is not true - a pointer to turn into "an object that might not be there" - this is completely expected,
mainly because people already see references as "the object" (and rightfully so) and "might not there" is already established clearly by optional itself.

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing. Unless you want pointers pointing to invalid
addresses, and I am sure you don't :-)

Cheers,
Miguel

[Tony V E]

End pointers (like end iterators) point to non-objects.


Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Miguel Ojeda
Sent: Thursday, October 25, 2018 3:41 PM
To: std-***@isocpp.org
Reply To: std-***@isocpp.org
Subject: Re: [std-proposals] shared_ptr and unique_ptr should both implicitly convert to observer_ptr

On Thu, Oct 25, 2018 at 7:34 PM Ville Voutilainen

Post by Ville Voutilainen

- observer_ptr was never requested (as it is trivial to implement if one wants it, and by no mean all people want it)

It appeared out of thin air? It was approved into the TS even though
nobody wants it?

If we move with observer_ptr we must reject optional<X&> first.
I am OK either way, but the decision must be weighted extremely carefully, based on use cases and people needs and expectations.
For instance I doubt anyone can anticipate optional to turn into a pointer. It is simply unexpected, learnable, but unexpected.
Where the reverse is not true - a pointer to turn into "an object that might not be there" - this is completely expected,
mainly because people already see references as "the object" (and rightfully so) and "might not there" is already established clearly by optional itself.

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing. Unless you want pointers pointing to invalid
addresses, and I am sure you don't :-)

Cheers,
Miguel
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72mByDkQB3C0nfUegzYRD30T3B15HMw2_yiQvBPUH7D2%2Bw%40mail.gmail.com.

[Miguel Ojeda]

Post by Tony V E
End pointers (like end iterators) point to non-objects.

Then it is not an observer_ptr, because it does not observe anything ;-)

Seriously: on one hand you argue "we need modern C++", on the other
hand, you want to go for yet another pointer type, when the actual
semantics you want is either optional references (as in built-in) or
optional of references (as in optional<T&>). Further, if you want
iterators, you should write an iterator class, not an observer_ptr and
use it as such.

To me, observer_ptr is going in the wrong direction, i.e. "older C++".
I agree that the idea on itself can help some projects (e.g. those
that are already passing everywhere smart pointers) and maybe you can
argue you want it in the standard "for completeness". However, I don't
agree it is the best approach.

Cheers,
Miguel

[Ville Voutilainen]

On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.

Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

Cheers,
Miguel

[Ville Voutilainen]

On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda

Post by Miguel Ojeda
On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.
Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

It is equally simple for you to show how they are the same,
apparently. If you want to complain
about rudeness, then stop making claims with zero evidence and then
complaining when they are not
blindly accepted.

[Barry Revzin]

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda

Post by Miguel Ojeda
On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter

can

Post by Miguel Ojeda

Post by Ville Voutilainen

Post by Miguel Ojeda

Post by Ville Voutilainen
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The

former

Post by Miguel Ojeda

Post by Ville Voutilainen

Post by Miguel Ojeda

Post by Ville Voutilainen
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.
Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

It is equally simple for you to show how they are the same,
apparently. If you want to complain
about rudeness, then stop making claims with zero evidence and then
complaining when they are not
blindly accepted.

Saying we don't need optional<T&> because we have observer_ptr<T> (or vice
versa) is roughly equivalent to saying we don't need string_view because we
already have pair<char const*, size_t>.

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 10:01 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:55, Miguel Ojeda

Post by Miguel Ojeda
"Feel free to try again", excuse me? Being rude won't help your case.
Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

It is equally simple for you to show how they are the same,
apparently.

Not at all. I claimed they are the same, since I don't know any
practical difference. You claimed you *do* know some difference, so I
simply asked that you state it, since you *already* know it -- as you
have claimed. Therefore, it should be simpler for you.

Post by Ville Voutilainen
If you want to complain
about rudeness, then stop making claims with zero evidence and then
complaining when they are not
blindly accepted.

Even if it was true I gave "zero evidence" (which it isn't), that
doesn't mean I am being rude. However, you are being rude by stating
publicly "you are wrong; feel free to try again", as if I had to prove
something. No, sorry, the one making the proposal is you, so *you* are
the one that has to prove its validity.

Cheers,
Miguel

[Ville Voutilainen]

On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda

Post by Miguel Ojeda
Even if it was true I gave "zero evidence" (which it isn't), that
doesn't mean I am being rude. However, you are being rude by stating
publicly "you are wrong; feel free to try again", as if I had to prove
something. No, sorry, the one making the proposal is you, so *you* are
the one that has to prove its validity.

Let's repeat, then:

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

Furthermore,
1) I am not making a proposal.
2) If I were, I wouldn't waste my time explaining it here.

[Tony V E]

On Thu, Oct 25, 2018 at 4:59 PM Ville Voutilainen <

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda

Post by Miguel Ojeda
Even if it was true I gave "zero evidence" (which it isn't), that
doesn't mean I am being rude. However, you are being rude by stating
publicly "you are wrong; feel free to try again", as if I had to prove
something. No, sorry, the one making the proposal is you, so *you* are
the one that has to prove its validity.

An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".
I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.
Furthermore,
1) I am not making a proposal.
2) If I were, I wouldn't waste my time explaining it here.

Also, a container of observer_ptrs would sort by the pointer value (ie
address).
I'm not sure how optional<T&> would sort, and if it would be sortable at
all.

[Miguel Ojeda]

Also, a container of observer_ptrs would sort by the pointer value (ie address).
I'm not sure how optional<T&> would sort, and if it would be sortable at all.

Well, same as optional<T>, no? i.e. sort by the T, which seems to be
more useful than by address, i.e. you rarely need pointers/addresses
sorted; but sorting actual objects by their own defined order is
useful. So I would say it is an advantage for optional<T&> here.

A bit off-topic, but maybe you know the answer: I am not really sure
of what was the value of making (in general) _ptr's sortable,
specially considering you may provide the comparison function if
needed very easily (.get()). I guess it was made like that to make
them behave "more like pointers", but I don't think there are many use
cases...

Cheers,
Miguel

[Balog Pal]

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

May be a language problem but I still fail to see a practical
difference. Like one between "I do nothing" and "I don't do anything".

The null pointer and the empty opt_ref both designate no object at the
other end while a non-null pointer and the nonempty ref does.

(really just weighing to to point out that the difference you see is not
at all evident, and the previous poster is not baffled alone)

Post by Ville Voutilainen
I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

unless you use the value_or() interface -- but the whole usage makes
even less sense. observer_ptr looks superfluous enough being just a
pointer-wrapper compared to raw pointers (I assign low value to
protection from using + and [] with it), but okay, let's substitute our
pointers with that. So we will pass them around and use */-> and the
bool check.

What kind of system want to extract the raw pointer from it?

Post by Ville Voutilainen

Post by Peter Koch Larsen
Well... writing modern C++ (in my sense of modern) it is. A raw

pointer is newer owned.

Post by Ville Voutilainen
This is, to me, a fairly astonishing part of what some call "modern"
C++. Instead of enforcing semantics with
a type, they are loosely agreed on by an unenforceable convention.
That seems like a massive
step backwards, instead of being modern.

I somewhat agree with going against "modern" here, as that is IME one of
the most fundamental guides we use in C++ I use approaching 30 years.

Wasn't RAII the main feature of C++ from boot? Is "resource allocation"
it designates mean really *ownership*? Isn't owning pointer looking at a
resource that is supposed to stand out? Granted immediately to care of
some handling type?

IMNSHO the guideline to not having raw pointers with ownership sitting
around in a program is one of the few universally agreed upon.

And if we put it to use, what the remaining pointers will be if not
non-owning observers?

Tony said upstream "When you have a raw pointer, ownership is not
(typically) obvious." -- I say if that holds for your project you are in
deep trouble.

I did join several such projects and one of the first tasks were to
address this very mess. And I did not expect the bug count go down
before that cleanup done.

Where "modern" C++ helped was adding the move semantics to the language,
so many typical owners now can revert to natural state, no longer
forcing shared_ptr or homemade refcounted pointers where we really never
meant sharing, just convenient way to pass a thing between 2 points in
code.

[m***@gmail.com]

Post by Balog Pal

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

May be a language problem but I still fail to see a practical
difference. Like one between "I do nothing" and "I don't do anything".
The null pointer and the empty opt_ref both designate no object at the
other end while a non-null pointer and the nonempty ref does.
(really just weighing to to point out that the difference you see is not
at all evident, and the previous poster is not baffled alone)

Post by Ville Voutilainen
I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

unless you use the value_or() interface -- but the whole usage makes
even less sense. observer_ptr looks superfluous enough being just a
pointer-wrapper compared to raw pointers (I assign low value to
protection from using + and [] with it), but okay, let's substitute our
pointers with that. So we will pass them around and use */-> and the
bool check.
What kind of system want to extract the raw pointer from it?

As pointed out - there is a difference in hashing and sorting.
One is wrapper of an object the other of a pointer object (and we use
trickery to pretend it is an object wrapped)

So, they are observably not the same.

Post by Balog Pal

Post by Ville Voutilainen

Post by Peter Koch Larsen
Well... writing modern C++ (in my sense of modern) it is. A raw

pointer is newer owned.

Post by Ville Voutilainen
This is, to me, a fairly astonishing part of what some call "modern"
C++. Instead of enforcing semantics with
a type, they are loosely agreed on by an unenforceable convention.
That seems like a massive
step backwards, instead of being modern.

I somewhat agree with going against "modern" here, as that is IME one of
the most fundamental guides we use in C++ I use approaching 30 years.
Wasn't RAII the main feature of C++ from boot? Is "resource allocation"
it designates mean really *ownership*? Isn't owning pointer looking at a
resource that is supposed to stand out? Granted immediately to care of
some handling type?
IMNSHO the guideline to not having raw pointers with ownership sitting
around in a program is one of the few universally agreed upon.
And if we put it to use, what the remaining pointers will be if not
non-owning observers?
Tony said upstream "When you have a raw pointer, ownership is not
(typically) obvious." -- I say if that holds for your project you are in
deep trouble.

The problem is that this relies on discipline.
Even if you have the discipline part, because the compiler can't
differentiate b/w owning and no-owning
you are forced into an explicit interface - you are forced to use get().

We are trading the simplicity of a convention for the fact a non-owning
pointer becomes
a form of "private implementation", something that one

A) must request explicit permission to access
B) must "proceed with caution" ones obtained

This is the issue an observing pointer solves - it promotes pointers again
to first class citizens.

To have something like this could help not just old codebases, but new
users as well.
We will be able to say "modern C++ pointers are safe" and prove it by
having implicit conversion from a smart pointer
(which we already recommend for memory management).

Raw pointers will be left for pointer arithmetics, interop and low level
private implementations.


Having said that, many if not the majority of people will prefer to have
optional reference as a nullable reference type to represent objects

At this point, I think we should have both and both should be implicitly
constructible from pointers, possibly from one another also.

Post by Balog Pal
I did join several such projects and one of the first tasks were to
address this very mess. And I did not expect the bug count go down
before that cleanup done.
Where "modern" C++ helped was adding the move semantics to the language,
so many typical owners now can revert to natural state, no longer
forcing shared_ptr or homemade refcounted pointers where we really never
meant sharing, just convenient way to pass a thing between 2 points in
code.

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda

Post by Miguel Ojeda
Even if it was true I gave "zero evidence" (which it isn't), that
doesn't mean I am being rude. However, you are being rude by stating
publicly "you are wrong; feel free to try again", as if I had to prove
something. No, sorry, the one making the proposal is you, so *you* are
the one that has to prove its validity.

That is not an example of a difference, sorry. If you can't come up
with an easy example, maybe you should consider there isn't any
practical difference. Which is *fine*, but it subtracts from the total
value of the proposal, in my view (i.e. it would be bloat).

Post by Ville Voutilainen
Furthermore,
1) I am not making a proposal.

You are suggesting that observer_ptr is a good idea. It doesn't need
to be a formal proposal to be one, specially in std-proposals, I would
say.

Post by Ville Voutilainen
2) If I were, I wouldn't waste my time explaining it here.

That is interesting. Why is that? If you think, as a part of the
committee, that there is little of no value in discussing proposals
here (formal ones or not), it would be good to know.

Cheers,
Miguel

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

[Forgot to reply to this]

That, again, is *no* difference. You can create a two-way function
that maps empty optional<T&> to a nullptr. The only cases which would
be impossible to represent with an optional<T&> are all the
non-nullptr & non-valid pointers/addresses, which is what I said in
the beginning and Tony replied to. Again: the nullptr case is not one
of those.

Cheers,
Miguel

[Gašper Ažman]

Differences:

void foo(T* x);

observer_ptr<T> p:
optional<T&> opt;

foo(p.get());
foo(opt?&*opt:nullptr);

plus, the hashing on observer pointers is the hash of the pointer value,
and in the case where I want a set of unique optional object references I
have to specify my own hash on the `&*opt`s again.

Basically, despite the fact that there is a bijection, they are not
equivalent in usage. We can very well have both, with good guidelines on
when to use each, and perhaps two-way conversions to boot.

G


On Fri, Oct 26, 2018 at 10:40 AM Miguel Ojeda <

Post by Miguel Ojeda
On Thu, Oct 25, 2018 at 10:59 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 23:31, Miguel Ojeda
I can always get the pointer value from an observer_ptr. I can't get a
value from an optional<T&> when it has none.

[Forgot to reply to this]
That, again, is *no* difference. You can create a two-way function
that maps empty optional<T&> to a nullptr. The only cases which would
be impossible to represent with an optional<T&> are all the
non-nullptr & non-valid pointers/addresses, which is what I said in
the beginning and Tony replied to. Again: the nullptr case is not one
of those.
Cheers,
Miguel
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANiq72kOHDe28rHekVQ9Ov%2BOuXZ2wMnH-CQ__PRD4%2BnB_pLAEw%40mail.gmail.com
.

[Miguel Ojeda]

Post by Gašper Ažman
void foo(T* x);
optional<T&> opt;
foo(p.get());
foo(opt?&*opt:nullptr);

I don't see the problem, you have some impedance one way or the other.
If we get "optional<T&>", it is reasonable to think we would also get
a "opt.as_ptr()" or similar for this case.

Post by Gašper Ažman
plus, the hashing on observer pointers is the hash of the pointer value, and in the case where I want a set of unique optional object references I have to specify my own hash on the `&*opt`s again.

Ditto.

Post by Gašper Ažman
Basically, despite the fact that there is a bijection, they are not equivalent in usage. We can very well have both, with good guidelines on when to use each, and perhaps two-way conversions to boot.

I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
However, why do you say they are not equivalent in usage? (or rather:
why shouldn't they be?).

Cheers,
Miguel

[m***@gmail.com]

Post by Miguel Ojeda

Post by Gašper Ažman
void foo(T* x);
optional<T&> opt;
foo(p.get());
foo(opt?&*opt:nullptr);

I don't see the problem, you have some impedance one way or the other.
If we get "optional<T&>", it is reasonable to think we would also get
a "opt.as_ptr()" or similar for this case.

Post by Gašper Ažman
plus, the hashing on observer pointers is the hash of the pointer value,

and in the case where I want a set of unique optional object references I
have to specify my own hash on the `&*opt`s again.
Ditto.

Post by Gašper Ažman
Basically, despite the fact that there is a bijection, they are not

equivalent in usage. We can very well have both, with good guidelines on
when to use each, and perhaps two-way conversions to boot.
I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
why shouldn't they be?).

You yourself agreed one must be hashed and compared on the pointed-to
object, the other on itself. This makes them not-equivalent in usage.

Why should one pay for expensive hash on object if the objects he has
interest in are already with unique address?
Likewise why should I pay for expansive compare if the objects I have
interest in have pointers that I can put in a vector, sort it, and binary
search with lighting speed.

And is it a good thing to go to all the trouble to have special hash and
compare to take advantage of this opt.as_ptr(), if you want the above
behavior?
Is this a good API?

No one is denying the need for optional ref, arguably even their
superiority for object representation, but to state they cover the need for
observer_pr is a stretch.

Post by Miguel Ojeda
Cheers,
Miguel

[Dejan Milosavljevic]

If shared_ptr and unique_ptr can be implicitly converted to observe_ptr (
what ever name is ) what is the point of weak_ptr?

Let me generalize this for a little bit?
Does this lead to inheritance hierarchy of smart pointers?

template < typename T, ... > class shared_ptr : public pure_ptr<T>{... };
template < typename T, ... >class unique_ptr : public pure_ptr<T>{... };
template < typename T, ... >class clone_ptr : public pure_ptr<T>{... };
template < typename T, ... >class whatever_ptr : public pure_ptr<T>{... };
void f( pure_ptr<T> & p ){ p->release(); }



So far I see two ways of developing *_ptr's?
1. Inheritance hierarchy like in above example?
2. Conversion from one class to another like what we have now.
Might be better solution if for some reason there is a need for
deprecation. We already have this situation with auto_ptr.

Post by m***@gmail.com

Post by Miguel Ojeda

Post by Gašper Ažman
void foo(T* x);
optional<T&> opt;
foo(p.get());
foo(opt?&*opt:nullptr);

I don't see the problem, you have some impedance one way or the other.
If we get "optional<T&>", it is reasonable to think we would also get
a "opt.as_ptr()" or similar for this case.

Post by Gašper Ažman
plus, the hashing on observer pointers is the hash of the pointer

value, and in the case where I want a set of unique optional object
references I have to specify my own hash on the `&*opt`s again.
Ditto.

Post by Gašper Ažman
Basically, despite the fact that there is a bijection, they are not

equivalent in usage. We can very well have both, with good guidelines on
when to use each, and perhaps two-way conversions to boot.
I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
why shouldn't they be?).

You yourself agreed one must be hashed and compared on the pointed-to
object, the other on itself. This makes them not-equivalent in usage.
Why should one pay for expensive hash on object if the objects he has
interest in are already with unique address?
Likewise why should I pay for expansive compare if the objects I have
interest in have pointers that I can put in a vector, sort it, and binary
search with lighting speed.
And is it a good thing to go to all the trouble to have special hash and
compare to take advantage of this opt.as_ptr(), if you want the above
behavior?
Is this a good API?
No one is denying the need for optional ref, arguably even their
superiority for object representation, but to state they cover the need for
observer_pr is a stretch.

Post by Miguel Ojeda
Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%40isocpp.org?utm_medium=email&utm_source=footer>
.

[Richard Hodges]

Post by Dejan Milosavljevic
If shared_ptr and unique_ptr can be implicitly converted to observe_ptr (
what ever name is ) what is the point of weak_ptr?

weak_ptr observes and locks lifetime. It is not de-referenceable. It's a
very different _ptr. In hindsight, it probably shouldn't be called weak
*_ptr* at all.

If I were to create the shared_*xxx* idea from scratch, I'd probably be
thinking in terms of shared_owner, weak_reference etc.

imagine please:

template<class T> struct shared_owner {
...
operator T& () const; // which would throw or abort if we weren't an
owner of anything.
operator optional<T&> () const noexcept; // query
...
};

template<class T> struct weak_reference {
...
shared_owner<T> promote() const; // as per std::shared_ptr::lock(), but
returning a reference type
...
};

which would then allow interfaces to be correctly written in terms of
semantics:

void something(T&); // demands a T&
void something_else(optional<T&>); // loudly stating that we may or may
not need a T&
void something_else_that_stores(shared_owner<T>); // loudly stating that
we will share ownership

which would allow:

int main()
{
shared_owner<Foo> foo = make_shared_owner<Foo>(...);

if (foo) something(foo);
try {
something(foo); // will loudly break here if foo is empty.
} catch(empty_reference& e) {
//
}
something_else(foo); // always legal
}

No de-referencing, no noisy pointer stuff and provided we defer to
functions that require a Foo&, we can treat this type as a value and not a
pointer.

I can't think of any *semantic* reason to use pointers in a program. There
are practical reasons, such as interfacing with libraries and convenient
(for the writer) shortcuts for the *concepts* of references and
optionality. But not *conceptually defensible* reasons.

*Semantically,* there are iterators and there are [optional] references. We
have pointers because c++ came from c, and c is a handy macro-assembler.
For the first 20 or so years of C, *pointers* and *address or index
registers* were thought of as the same thing. They probably still are. This
is literally how I used to teach assembly programmers C:
- "what's a pointer?"
- "it compiles down to an address register, which will spill into memory
allocated on the stack if you use too many of them, so never use more than
three in a function"
(this was in the days of the M68000)

C++ is trying to be a higher level close-to-the-metal language. In order to
do that we try to create classes that represent conceptual operations and
ideas, but which boil down to a few, or zero, machine instructions on a
release build.

I suspect when boost::shared_ptr was first conceived, this sea change in
thinking in c++ hadn't quite happened.

Post by Dejan Milosavljevic
Let me generalize this for a little bit?
Does this lead to inheritance hierarchy of smart pointers?
template < typename T, ... > class shared_ptr : public pure_ptr<T>{... };
template < typename T, ... >class unique_ptr : public pure_ptr<T>{... };
template < typename T, ... >class clone_ptr : public pure_ptr<T>{... };
template < typename T, ... >class whatever_ptr : public pure_ptr<T>{... };
void f( pure_ptr<T> & p ){ p->release(); }
So far I see two ways of developing *_ptr's?
1. Inheritance hierarchy like in above example?
2. Conversion from one class to another like what we have now.
Might be better solution if for some reason there is a need for
deprecation. We already have this situation with auto_ptr.

Post by m***@gmail.com

Post by Miguel Ojeda

Post by Gašper Ažman
void foo(T* x);
optional<T&> opt;
foo(p.get());
foo(opt?&*opt:nullptr);

I don't see the problem, you have some impedance one way or the other.
If we get "optional<T&>", it is reasonable to think we would also get
a "opt.as_ptr()" or similar for this case.

Post by Gašper Ažman
plus, the hashing on observer pointers is the hash of the pointer

value, and in the case where I want a set of unique optional object
references I have to specify my own hash on the `&*opt`s again.
Ditto.

Post by Gašper Ažman
Basically, despite the fact that there is a bijection, they are not

equivalent in usage. We can very well have both, with good guidelines on
when to use each, and perhaps two-way conversions to boot.
I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
why shouldn't they be?).

You yourself agreed one must be hashed and compared on the pointed-to
object, the other on itself. This makes them not-equivalent in usage.
Why should one pay for expensive hash on object if the objects he has
interest in are already with unique address?
Likewise why should I pay for expansive compare if the objects I have
interest in have pointers that I can put in a vector, sort it, and binary
search with lighting speed.
And is it a good thing to go to all the trouble to have special hash and
compare to take advantage of this opt.as_ptr(), if you want the above
behavior?
Is this a good API?
No one is denying the need for optional ref, arguably even their
superiority for object representation, but to state they cover the need for
observer_pr is a stretch.

Post by Miguel Ojeda
Cheers,
Miguel

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ba622e7f-9a4a-4c48-914a-63b65a2f1c1c%40isocpp.org?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmya90yshUgGSfDSoTbts%3D4bdRhgrsdKdsR0dR5b4cdsrg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

--
Richard Hodges
***@gmail.com
office: [phone]
home: [phone]
mobile: [phone] (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r

[Miguel Ojeda]

Post by Miguel Ojeda
I agree we can have both, but not for that reason. I see observer_ptr
more as a completeness thing for C++, or for people that prefer that.
why shouldn't they be?).

You yourself agreed one must be hashed and compared on the pointed-to object, the other on itself. This makes them not-equivalent in usage.

I talked about whether it is more useful to have comparison functions
that work on T, or on the "address". If I have a optional<T&>, I want
the comparison to be done based on T, not the address. If I have
observer_ptr<T>, I want it on the address. I think we agree on that.

Why should one pay for expensive hash on object if the objects he has interest in are already with unique address?
Likewise why should I pay for expansive compare if the objects I have interest in have pointers that I can put in a vector, sort it, and binary search with lighting speed.

No one pays for anything: as I said, a T*, a observer_ptr<T>, a
optional<T&> etc. can all be used for that; with more or less
impedance depending on the interface of each. What I simply tried to
say is that, if we are trying to solve the "optional references"
problem, we should maybe go for that, instead of adding more and more
types that represent the same thing (and only differ in the interface
they present).

By the way, note that the case you presented (binary search on
observer_ptr), it is quite dangerous. If I store raw pointers
anywhere, I would probably use a T* (nor optional<T&>, nor
observer_ptr<T>), to indicate they are precisely that :-) I would
probably only use optional<T&> or observer_ptr<T> for arguments to
functions.

Cheers,
Miguel

[m***@gmail.com]

Post by Miguel Ojeda
On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The

former

Post by Ville Voutilainen

Post by Miguel Ojeda

Post by Ville Voutilainen
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.
Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

Well, one is an object wrapper, the other is pointer wrapper.

If the pointer (as an object) is of importance then observer_ptr is more
logical.
For example if you store it in a set, you might reach for observer_ptr
first as it maps really well to the mental model of "a handle" that can be
hashed on its value.

optional ref is much more higher level - it tries to present a real object
it does not have that handle aspect of it and to get to the real pointer
would be hard and unintuitive.
People will reach for it to be a view of on object or sub-object, but when
they need to put it a set, they might wonder - will this hash on "the
pointer" or on the object.



Yet having both seems overkill and if we do, what we would recommend as a
go-to interface if one does not want to force normal reference on its users
and we advise against memory managing types in interfaces.

Post by Miguel Ojeda
Cheers,
Miguel

[Miguel Ojeda]

Post by m***@gmail.com

Post by Miguel Ojeda
On Thu, Oct 25, 2018 at 9:49 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 22:41, Miguel Ojeda

Post by Miguel Ojeda

Post by Ville Voutilainen
An optional<T&> doesn't do what observer_ptr<T> does. The latter can
give you a null pointer when you ask its pointer value, so it can
model
"yes, I have a pointer, but it doesn't point to anything". The former
models "I may or may not have anything".

That is the same thing.

Yeah, except that it isn't, so feel free to try again.

"Feel free to try again", excuse me? Being rude won't help your case.
Give an example where it would make a difference, or acknowledge there
isn't one. It is that simple.

Well, one is an object wrapper, the other is pointer wrapper.
If the pointer (as an object) is of importance then observer_ptr is more logical.
For example if you store it in a set, you might reach for observer_ptr first as it maps really well to the mental model of "a handle" that can be hashed on its value.

I would agree with this if we thought pointers were the important part
of the construction. But I don't see how the pointer is the important
bit here. Yes, there are cases where pointers are "the" value you care
about (e.g. in a kernel), but in that case you should have a Pointer
class, not an observer_ptr. In other words: if you use an
observer_ptr, it is simply because you are modelling "I have a pointer
to access T"; what is important there is accessing the T, not the
actual value of the pointer.

Post by m***@gmail.com
optional ref is much more higher level - it tries to present a real object it does not have that handle aspect of it and to get to the real pointer would be hard and unintuitive.

Exactly!

Post by m***@gmail.com
People will reach for it to be a view of on object or sub-object, but when they need to put it a set, they might wonder - will this hash on "the pointer" or on the object.

If you put it on a set, 99.9% of the time you care about the T, and
want the sorting on the T; not on pointer values, I would say.
Therefore, optional<T&> is the winner here, because observer_ptr would
be sorted by the pointer, which doesn't make sense in the majority of
cases.

Cheers,
Miguel

[m***@gmail.com]

I have been playing around in my code with observer-like pointer and
honestly,
the verbosity is noticeable if are to compare with raw pointers and
references

The "issue" is that, in contrast to string_view, we have to also both name
a type and const-decorate

So in the end

void func(const IccProfile* profile)
void func(const IccProfile& profile)

are quite less verbose then

void func(std::observer_ptr<const IccProfile> profile)

This *will* force users to typedef, which I don't think is good idea and
not a price people will be willing to pay

Controversial or not I believe std::ptr<> is a more realistic, in terms of
adoption, option.
And is not bad of name:
- By omitting a name (like shared, weak, unique) it is implied it does
nothing.
- By the fact it is an std:: object it is implied it is "the C++ (object)
pointer", in contrast to "the C pointer" (the raw one)

Post by Tony V E

Post by Tony V E

Post by Tony V E
On Thu, Oct 25, 2018 at 1:20 AM Ville Voutilainen <

Post by Ville Voutilainen

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth

standardizing.

Post by Tony V E

Post by Ville Voutilainen
You said that before, but the paper didn't materialize. :P

... yet.
Hopefully next meeting.

Alright; give me the gist of the changes you have in mind, and if you
can, any drafts of the paper and I'll give you
a regtested proper stdlib implementation that has passed the tests of
observer_ptr, modulo changes needed for the changes
we need to make.

https://github.com/tvaneerd/isocpp/blob/master/observer_ptr.md#changes
<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftvaneerd%2Fisocpp%2Fblob%2Fmaster%2Fobserver_ptr.md%23changes&sa=D&sntz=1&usg=AFQjCNHPh-HIv_ZAUVLj_Vz2m06hmPGNTg>
I'm not sure it is worth making coding changes yet. Up to you of course.
Now that I think of it, the implicit conversions should probably be on
shared_ptr and unique_ptr cast operators, not on observer_ptr constructors.
(ie observer_ptr is the simpler class, it shouldn't depend on
shared/unique, they should depend on it)
Alternatively observer_ptr could have implicit conversion from anything
that "looks like" a smart pointer? Not sure how "looks like" would be
safely defined.

Post by Tony V E
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYRmaYmc12EfaUiBHiO1_t-2z2fE7NvdnJvkcWEhCoNSg%40mail.gmail.com
.

--
Be seeing you,
Tony

[p***@lib.hu]

2018. október 24., szerda 23:58:28 UTC+2 időpontban Tony V E a következőt

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.
Only question: observer_ptr is a terrible name, what should we call it.

Why should we call it anything? Isn't observer the *default *genre of
pointers? There is some merit to have owner_ptr to mark the interface where
ownership is passed before it gets into a dedicated owner. But who really
wants to noise up the codebase stating the (supposedly) obvious?

[Tony V E]

<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">When you have a raw pointer, ownership is not (typically) obvious.</div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>***@lib.hu</div><div><b>Sent: </b>Thursday, October 25, 2018 8:44 AM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b>std-***@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] shared_ptr and unique_ptr should both implicitly convert to observer_ptr</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr"><br><br>2018. október 24., szerda 23:58:28 UTC+2 időpontban Tony V E a következőt írta:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">I agree with all of this, and, to me, it makes observer_ptr worth standardizing.<div class="gmail_quote"><div><br></div><div>Only question: observer_ptr is a terrible name, what should we call it.<br></div></div></div></blockquote><div><br></div><div>Why should we call it anything? Isn't observer the <i>default </i>genre of pointers? There is some merit to have owner_ptr to mark the interface where ownership is passed before it gets into a dedicated owner.&nbsp; But who really wants to noise up the codebase stating the (supposedly) obvious?<br></div><div>&nbsp;</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=email&amp;utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com</a>.<br />

[Peter Koch Larsen]

Post by Tony V E
When you have a raw pointer, ownership is not (typically) obvious.

Well... writing modern C++ (in my sense of modern) it is. A raw pointer is
newer owned.

Post by Tony V E
Sent from my BlackBerry portable Babbage Device
*Sent: *Thursday, October 25, 2018 8:44 AM
*To: *ISO C++ Standard - Future Proposals
*Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both
implicitly convert to observer_ptr
2018. október 24., szerda 23:58:28 UTC+2 időpontban Tony V E a következőt

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.
Only question: observer_ptr is a terrible name, what should we call it.

Why should we call it anything? Isn't observer the *default *genre of
pointers? There is some merit to have owner_ptr to mark the interface where
ownership is passed before it gets into a dedicated owner. But who really
wants to noise up the codebase stating the (supposedly) obvious?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com?utm_medium=email&utm_source=footer>
.

[Ville Voutilainen]

On Thu, 25 Oct 2018 at 16:19, Peter Koch Larsen

Post by Tony V E
When you have a raw pointer, ownership is not (typically) obvious.

Well... writing modern C++ (in my sense of modern) it is. A raw pointer is newer owned.

This is, to me, a fairly astonishing part of what some call "modern"
C++. Instead of enforcing semantics with
a type, they are loosely agreed on by an unenforceable convention.
That seems like a massive
step backwards, instead of being modern.

[Miguel Ojeda]

On Thu, Oct 25, 2018 at 3:28 PM Ville Voutilainen

Post by Ville Voutilainen
On Thu, 25 Oct 2018 at 16:19, Peter Koch Larsen

Post by Tony V E
When you have a raw pointer, ownership is not (typically) obvious.

Well... writing modern C++ (in my sense of modern) it is. A raw pointer is newer owned.

This is, to me, a fairly astonishing part of what some call "modern"
C++. Instead of enforcing semantics with
a type, they are loosely agreed on by an unenforceable convention.
That seems like a massive
step backwards, instead of being modern.

That has nothing to do with modern C++, though. T* is a perfectly
valid solution for optional references.

On top of that, the logic does not really follow: if you are writing
"modern C++", then you don't have any raw pointer owning anything.
Therefore, a raw pointer has to be an observer one.

Cheers,
Miguel

[Tony V E]

<html><head></head><body lang="en-US" style="background-color: rgb(255, 255, 255); line-height: initial;"> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">But then going back to the original post, do you allow shared_ptr to implicitly convert to T*?&nbsp;</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">And thus allow `delete mySharedPtr;`?</div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></div> <div style="width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br style="display:initial"></div> <div style="font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div> <table width="100%" style="background-color:white;border-spacing:0px;"> <tbody><tr><td colspan="2" style="font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"> <div style="border-style: solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;"> <div><b>From: </b>Peter Koch Larsen</div><div><b>Sent: </b>Thursday, October 25, 2018 9:19 AM</div><div><b>To: </b>std-***@isocpp.org</div><div><b>Reply To: </b>std-***@isocpp.org</div><div><b>Subject: </b>Re: [std-proposals] shared_ptr and unique_ptr should both implicitly convert to observer_ptr</div></div></td></tr></tbody></table><div style="border-style: solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br><div id="_originalContent" style=""><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 25, 2018 at 2:54 PM Tony V E &lt;<a href="mailto:***@gmail.com">***@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div lang="en-US" style="background-color:rgb(255,255,255)"> <div style="width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)">When you have a raw pointer, ownership is not (typically) obvious.</div> <div style="width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)"><br></div></div></blockquote><div>&nbsp;</div><div>Well... writing modern C++&nbsp;(in my sense of modern) it is. A raw pointer is newer owned.</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div lang="en-US" style="background-color:rgb(255,255,255)"><div style="width:100%;color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)"></div> <div style="color:rgb(31,73,125);font-family:Calibri,&quot;Slate Pro&quot;,sans-serif,sans-serif;background-color:rgb(255,255,255)">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div> <table width="100%" style="border-spacing:0px;background-color:white"> <tbody><tr><td style="background-color:rgb(255,255,255)" colspan="2"> <div style="border-style:solid none none;padding:3pt 0in 0in;font-family:Tahoma,&quot;BB Alpha Sans&quot;,&quot;Slate Pro&quot;;font-size:10pt;border-top-color:rgb(181,196,223);border-top-width:1pt"> <div><b>From: </b><a href="mailto:***@lib.hu" target="_blank">***@lib.hu</a></div><div><b>Sent: </b>Thursday, October 25, 2018 8:44 AM</div><div><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b><a href="mailto:std-***@isocpp.org" target="_blank">std-***@isocpp.org</a></div><div><b>Subject: </b>Re: [std-proposals] shared_ptr and unique_ptr should both implicitly convert to observer_ptr</div></div></td></tr></tbody></table><div style="border-style:solid none none;border-top-color:rgb(186,188,209);border-top-width:1pt;background-color:rgb(255,255,255)"></div><br><div id="m_3621262056988043521_originalContent"><div dir="ltr"><br><br>2018. október 24., szerda 23:58:28 UTC+2 időpontban Tony V E a következőt írta:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">I agree with all of this, and, to me, it makes observer_ptr worth standardizing.<div class="gmail_quote"><div><br></div><div>Only question: observer_ptr is a terrible name, what should we call it.<br></div></div></div></blockquote><div><br></div><div>Why should we call it anything? Isn't observer the <i>default </i>genre of pointers? There is some merit to have owner_ptr to mark the interface where ownership is passed before it gets into a dedicated owner.&nbsp; But who really wants to noise up the codebase stating the (supposedly) obvious?<br></div><div>&nbsp;</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org" target="_blank">std-proposals+***@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-***@isocpp.org" target="_blank">std-***@isocpp.org</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=email&amp;utm_source=footer" target="_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org</a>.<br>
<br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org" target="_blank">std-proposals+***@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-***@isocpp.org" target="_blank">std-***@isocpp.org</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com?utm_medium=email&amp;utm_source=footer" target="_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com</a>.<br>
</blockquote></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br>
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+***@isocpp.org">std-proposals+***@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-***@isocpp.org">std-***@isocpp.org</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025133153.5218385.87846.64230%40gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025133153.5218385.87846.64230%40gmail.com</a>.<br />

[m***@gmail.com]

The more I think about it, the more I feel std::optional<X&> is better
suited to be "non owning null-ble handle"

This is, if we make a list with pros and cons, pros seems to win

*Mega wins*

- Immune to ownership semantic issues
- Explicit, by name, "might not be there" meaning

*Pros*

- You can't even get() the pointer - it is as close to "object_view" as we
can get
- It is better suited to be destination implicit conversion for other
things like, optional itself - optional<X> converts to optional</*const*/
X&>, the same way string does to a view
- It is better to have a (smart) pointer convert to optional reference
then optional to a "observing pointer".
- People don't like "pointer" to stand-in for an object (*even if *
optional has the same interface!)
- People want it (and request it) for other things

*Cons*

- The only type in the std that will be either a reference type or a value
type, depending on param
- The entire interface is developed around value container type
- Construction and assignment from value might be debatable, *especially *if
we push it to replace raw pointers as observers (or observer_ptr for that
matter)


On the other hand observer_ptr

*Pros*

- No implicit conversion to raw
- Good fit to be implicit conversion target from smart and raw pointers
- By name not owning
- Little to no semantic problems - reference type, period

*Cons*
* - *Name and interface can be (very) misleading - "Observing what?
Lifetime?", "Observing, but not const, Wat?"
- Not well suited to be implicit conversion from other, non-politer-like
objects.
- It is still a pointer - people don't like them much
- It is still a pointer - one can still delete get() or delete release()it

Post by Tony V E
But then going back to the original post, do you allow shared_ptr to
implicitly convert to T*?
And thus allow `delete mySharedPtr;`?
Sent from my BlackBerry portable Babbage Device
*From: *Peter Koch Larsen
*Sent: *Thursday, October 25, 2018 9:19 AM
*Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both
implicitly convert to observer_ptr

Post by Tony V E
When you have a raw pointer, ownership is not (typically) obvious.

Well... writing modern C++ (in my sense of modern) it is. A raw pointer is
newer owned.

Post by Tony V E
Sent from my BlackBerry portable Babbage Device
*Sent: *Thursday, October 25, 2018 8:44 AM
*To: *ISO C++ Standard - Future Proposals
*Subject: *Re: [std-proposals] shared_ptr and unique_ptr should both
implicitly convert to observer_ptr
2018. október 24., szerda 23:58:28 UTC+2 időpontban Tony V E a következőt

Post by Tony V E
I agree with all of this, and, to me, it makes observer_ptr worth
standardizing.
Only question: observer_ptr is a terrible name, what should we call it.

Why should we call it anything? Isn't observer the *default *genre of
pointers? There is some merit to have owner_ptr to mark the interface where
ownership is passed before it gets into a dedicated owner. But who really
wants to noise up the codebase stating the (supposedly) obvious?
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/464c2586-4d3f-43e1-b135-d4c51436d672%40isocpp.org?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20181025125433.5218385.77798.64223%40gmail.com?utm_medium=email&utm_source=footer>
.

--
You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an
To view this discussion on the web visit
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANPtknxg98ZuW9jcVs%3De_hKYr3JF750vTRk%2B8m4hFWvm3imahw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

[Miguel Ojeda]

Hi Михаил,

- second writing a void f(const std::unique_ptr<T>&); actually buys something, it buys us transparent interface - that is why people do it!.

What do you mean by "transparent interface"? Being able to call with
"c" instead of "*c"? Also, I am not sure I have seen that many code
passing around references to `unique_ptr`. Typically you want a
reference, no?

The string situation is further improved
void f(std::string_view);

That is kind of a special case, no? i.e. strings typically come in
many flavors (specially due to C APIs/libs), so we provide a wrapper
to abstract that issue. However, normal C++ objects aren't usually put
in a C array, for instance. We could have a "vector_view" or
"sequence_view" too, but I don't think it is that needed (and we have
iterators anyway).

But does it have to be that way? Why not have
void f(observer_ptr<const X>);
instead of
void f(const T*);
AND
let std::unique_ptr<X> implicitly convert to observer_ptr<X>

It is a fine idea, but again, in my view, the signature should contain
references.

Also, some people actually prefer to have an annotations like "*c" or
"&c" at call site instead of simply "c". For instance, to signal
output parameters, to be explicit about dereferences... Why would you
take an observer_ptr is what you really want is the object (optional
or not)?

I would even prefer an "optional references" proposal rather than an
observer_ptr, so that we could keep use references everywhere with
ease, instead of moving to raw pointers or std::pointer. In other
words, being able to write something like (image "optional" is a
keyword):

void f(optional const T& value)
{
if (not optional value)
return;
// use value as usual
}

f(2); // reference with a value
f(optional); // empty reference

Cheers,
Miguel

[m***@gmail.com]

Hi МОхаОл,

- second writing a void f(const std::unique_ptr<T>&); actually buys

something, it buys us transparent interface - that is why people do it!.
What do you mean by "transparent interface"? Being able to call with
"c" instead of "*c"?

yes

Also, I am not sure I have seen that many code
passing around references to `unique_ptr`.

Well, every two years (literally) there are talks that tell the people "do
not do that".

Typically you want a
reference, no?

But if you use your object as smart pointer this becomes cumbersome and in
a way intuitive, though arguably correct

The string situation is further improved
void f(std::string_view);

That is kind of a special case, no? i.e. strings typically come in
many flavors (specially due to C APIs/libs), so we provide a wrapper
to abstract that issue. However, normal C++ objects aren't usually put
in a C array, for instance. We could have a "vector_view" or
"sequence_view" too, but I don't think it is that needed (and we have
iterators anyway).

The point is to not be a special case, but the default one (for observing)
and
vector_view is coming (in the from of span) and is already part of Core
Guidelines span.

Iterators are for templates, this is for concrete types - to have abstract
interface while still using concrete types (and interface / impl
separation).

But does it have to be that way? Why not have
void f(observer_ptr<const X>);
instead of
void f(const T*);
AND
let std::unique_ptr<X> implicitly convert to observer_ptr<X>

It is a fine idea, but again, in my view, the signature should contain
references.

It all depends how you want to present your interface to users - do you
want to have the null case handed for them or not
and do you want to have the interface be "natural", because ultimately with
get() and operator* you force the user to *adjust *to you interface.

This makes smart pointers second class citizens to both old pointers - the
good old times where you just use pointers like normal object handles -
and to other languages where the handle is used as-is on the call site
without explicit call to a converting function.

Also, some people actually prefer to have an annotations like "*c" or
"&c" at call site instead of simply "c". For instance, to signal
output parameters, to be explicit about dereferences...

As said, depends on what you want.
Right now the scenario "I just want to use my object, that is heap
allocated" is not handled naturally
and there is no way to do so outside accepting const smart_ptr<T>&

Why would you
take an observer_ptr is what you really want is the object (optional
or not)?

Because this is what the user has - he has pointer.

I would even prefer an "optional references" proposal rather than an
observer_ptr, so that we could keep use references everywhere with
ease, instead of moving to raw pointers or std::pointer. In other
words, being able to write something like (image "optional" is a
void f(optional const T& value)
{
if (not optional value)
return;
// use value as usual
}
f(2); // reference with a value
f(optional); // empty reference

I sympathize with the idea, but this is very hard to implement if we don't
want it to model a pointer (to not have indirections like operator* and
operator->)

I also don't like observer_ptr name very much and I am also not big fan of
the fact it pretends to be a smart point with fancy API (though I could see
uses for that in generic code).

However if this gives us "view for objects" with most (but not all) of the
benefits, that makes things quite interesting.

Technically, yeah the smart reference you decried is "view for objects" and
it is what we want/need, but we don't have that and the attempts to get one
failed multiple times ("operator dot" and family)

Cheers,
Miguel

[Miguel Ojeda]

Well, every two years (literally) there are talks that tell the people "do not do that".

Sure, people learning may do it, but that doesn't imply we need
something else, no?

But if you use your object as smart pointer this becomes cumbersome and in a way intuitive, though arguably correct

[1] A function shouldn't take a shared_ptr<T> or unique_ptr<T> (or
observer_ptr<T>, for that matter), if the only thing required is the
T. Unless the function needs the pointer itself, for some reason, the
signature should be a T or a T& (possible const-qualified) if
possible. That actually makes the function more flexible, because it
does not care where the object is stored nor who is the owner.

vector_view is coming (in the from of span) and is already part of Core Guidelines span.

Yeah, std::span is nice to abstract std::vectors away, but you can
achieve the same with iterators.

Iterators are for templates, this is for concrete types - to have abstract interface while still using concrete types (and interface / impl separation).

I am not sure I understand. Iterators are an orthogonal concept to templates.

It all depends how you want to present your interface to users - do you want to have the null case handed for them or not

Most of the functions I write do not need null/optional objects. For
those that do, I simply use T* (which has been the way of doing it
since forever! :-) because we do not have "optional references"
(otherwise I would use that instead).

and do you want to have the interface be "natural", because ultimately with get() and operator* you force the user to adjust to you interface.

That is a different topic, indeed. If you want to call functions with
"c", you are basically asking that implicit conversions happen from
pointer types to their actual values.

This makes smart pointers second class citizens to both old pointers - the good old times where you just use pointers like normal object handles -

See above [1].

and to other languages where the handle is used as-is on the call site without explicit call to a converting function.

It is not that there is no explicit conversion; rather, those
languages are always using references, so there is no conversion at
all. Basically, you can achieve the same thing in C++ by always,
always, always using a wrapper<T>, possibly with a GC. But then you
lose one key advantage of C++.

As said, depends on what you want.
Right now the scenario "I just want to use my object, that is heap allocated" is not handled naturally
and there is no way to do so outside accepting const smart_ptr<T>&

See above [1]: you should be saying "I just want to use my object, no
matter where it is allocated" instead.

I sympathize with the idea, but this is very hard to implement if we don't want it to model a pointer (to not have indirections like operator* and operator->)

I am not sure I understand this part.

Cheers,
Miguel