|
Boost : |
Subject: Re: [boost] compact_optional -- prompting interest
From: David Stone (david_at_[hidden])
Date: 2015-09-29 20:03:02
On Tue, Sep 29, 2015 at 2:16 AM, Andrzej Krzemienski <akrzemi1_at_[hidden]>
wrote:
> 2015-09-29 9:11 GMT+02:00 Gonzalo BG <gonzalobg88_at_[hidden]>:
>
> >
> >
> > @Andrzej: Right now your implementation allows constructing a
> > compact_optional from the sentinel value, which results in an empty
> > compact_optional. What is the motivation for this?
> >
> > In my fork I've disabled it for the following reasons:
> > - I'd rather use compact_optional's default constructor to explicitly
> state
> > that i'm constructing an empty optional, this made it easier to reason
> > about my code,
> > - the other constructors from value_type can then hint the compiler that
> > the compact_optional is not empty (but I did not profile so I don't know
> if
> > this has any impact at all).
> >
>
> The motivation for this was to enable an integration of compact_optional
> with older/other parts of the program that still use magical values:
>
> ```
> using Index = compact_optional<evp_int<string::size_type, string::npos>>
> string s = /*...*/
> Index i {s.find("substr")};
> ```
>
> In the above example, I will not be changing std, but want to change to
> compact_optional as soon as possible.
>
> But in fact, I could provide a dedicated conversion function for this use
> case. This aspect is still under consideration, so I may go with your
> suggestion.
>
> Regards,
> &rzej
>
In fact, I think constructing from the magic value is the primary use case
for such a class. This makes it easy to integrate with, for instance, a
networking protocol that has a magic value meaning "no value here". Now
that I've thought about it more, compact_optional is a way of saying that
you care exactly how that "not present" state is constructed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk