sob., 31 lip 2021 o 13:07 Ivan Matek via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
>> 2, "return bare pointer," is correct. The STL already uses this idiom in `std::get_if` and `std::any_cast`, as well as `std::dynamic_cast<T*>`.
>
> IMAO STL uses this wrong(more precisely suboptimal).
> Pointer is way too powerful for the return type of this kind of operation.
> There is absolutely no reason why one should be able to do arithmetic on returned value, call delete on it...
> I understand that this concerns might sound trivial to people reading this, but there are millions of C++ developers and many of them are not that good at C++, so it is nice to make things harder to misuse.
>

There was a floating idea of `observer_ptr` that could probably be
used in this case.
I would restrict unneeded operations (index operator will be available
only if its hold pointer to array).
I could have too some member functions that could throw in case of `nullptr`:
```
std::foo(map, "X").dref() = 10; //throw. could `value()` be misused as
an alternative name?
*std::foo(map, "X") = 10; //UB
```
It could share some monad operations to make it easy for some typical uses.

> Obviously this is personal opinion (similar to using strong types in general, practice of using most specialized algorithm when multiple will work fine, TOTW 112), but I would not just assume STL did it right in the past when discussing new ideas.
>
> @Kyle
> In general excellent proposal, maybe consider adding it to some open source library first.
> I have considered this problem long time ago, and thought maybe ofind would be a nicer short name(o is for optional), but then issue is that there is no ofind in <algorithm> so maybe value_for is best name...
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals