Re: [boost] [RFC] unique_val (handles, IDs, descriptors...)

Subject: Re: [boost] [RFC] unique_val (handles, IDs, descriptors...)
From: Miguel Ojeda (miguel.ojeda.sandonis_at_[hidden])
Date: 2018-02-14 22:39:29

On Wed, Feb 14, 2018 at 10:48 PM, Nevin Liber via Boost
<boost_at_[hidden]> wrote:
> On Wed, Feb 14, 2018 at 3:18 PM, Miguel Ojeda via Boost <
> boost_at_[hidden]> wrote:
>
>>     https://github.com/ojeda/unique_val
>
>
> IMO, such a class is definitely useful.

Thanks *a lot* for the almost instantaneous review! :)

>
> Design concerns:
>
>    - unique_val should be copyable if T is copyable.  Whether or not a type
>    which aggregates this is copyable is an orthogonal, separate concern from
>    what the moved-from state should be.  If you go this route, unique_val is
>    the wrong name.

As Steven mentions, it cannot be copyable since it is meant to hold
values where you need to perform an action on deletion once per value,
i.e. I meant "unique" here as the same as "unique_ptr" means: only one
"owner" is supposed to hold a given value.

>    - Instead of providing operator bool(), why not provide operator T&()
>    and operator T const&()?

Hum, that could be interesting, not sure of all the implications, though.

>    - What about comparisons of the form: unique_val<T, a> op unique_val<T,
>    b>?
>    - What about comparisons of the form: unique_val<T> op T (as well as T
>    op unique_val<T>)?

Indeed, I suggest the second ones in the Rationale as possible
extensions, I think they make quite a lot of sense. I thought about
the first ones, but I don't think they are that useful in practise,
since when you are using the unique_val, you already know what your
"invalid" or "moved-from" or "default" value has to be, so you will
not be using different ones (i.e. I don't think in practise
unique_val<T, x> and unique_val<T, y> where x != y is a common case).

>    - Propagate noexcept correctly, as it is dependent on the underlying
>    operations.

I thought that, given that T has to be a type suitable for the default
(which itself is a non-type template parameter), it couldn't be
anything throwing exceptions -- but I may be wrong here; please let me
know!

>    - Propagate constexpr correctly (for instance, your default constructor
>    should be constexpr).

Indeed, probably a few constexpr's are missing. I only added the
obvious get_default() one since I am not sure what are the best
practices for writing them for C++11, C++14 and C++17 at the same time
without breaking something. Since it was optional, I left it at that
for the moment.

Thanks a lot again!
Miguel

>
> --
>  Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
> [phone] <(847)%20691-1404>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost