czw., 25 maj 2023 o 15:32 Frederick Virchanza Gotham via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> I will reply to people in series below:
>
> Marcin Jaczewski wrote:
> >
> > No, standard should not allow this, reason is simple
> > you hide multiple indirections that some could be `nullptr` or empty:
> > ```
> > std::optional< std::optional<std::string>* > p { nullptr };
> > if (p) p->size(); // 2x UB and even if check look correct
> > (***p).size(); //easy to see that you need 3 checks
>
>
> In my code I check that the std::optional object contains a value, and
> if it does then the logic of my code is that the iterator is always
> valid.
>
> But anyway maybe we could have a new operator such as '->>' which
> stops when it encounters a nullptr. For example if you do:
>
> (***p).size(); // undefined behaviour
> p->>size(); // nothing happens
>

Yes, this is better, but question if it still worth committee time to specify
all details and corner cases to thing that can be handed by some
helper function:
```
opt_deep_deref(p, [](auto& x){ x.size() }); //work on any thing that
can `if(z)` and `*z` and is recursive.
```
more typing but you can make it today, even if you are very determined
to reduce typing you could
add macro `ODDR(p, x.size())`.


>
> Giuseppe D'Angelo wrote:
> > If it's the former, if you actually use any container that yields
> > forward iterators, you can just use a value-initialized iterator object
> > as "null iterator" https://eel.is/c++draft/forward.iterators#2 . Just
> > static_assert that your iterator models forward_iterator.
> >
> > If it's the latter, then there's nothing to worry about because
> > std::list never invalidates its end() iterator.
>
>
> I want the code to be generic so that the container can be changed
> later. I might end up using
> boost::lockfree::single_producer_single_consumer.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals