Re: [boost] compact_optional -- prompting interest

2015-09-26 23:34 GMT+02:00 Andrey Semashev :

...

2015-09-25 17:37 GMT+02:00 Andrey Semashev :

...

However, I'm not sure I agree with your rationale on the reduced

interface

...

and possibly the compact_optional naming.

1. You chose not to provide relational operators for compact_optional because you don't know how to order 'empty' values. I think you don't have to make that decision and simply forward the call to the underlying type. I mean, you always have the stored object constructed in some state and as long as it implements operators you can always use them.

So this is a trade-off between convenience/expressiveness and the

On Sat, Sep 26, 2015 at 7:52 PM, Andrzej Krzemienski wrote: potential

...

to detect unintended semantics at compile-time. If there is sufficient argumentation in favor of adding them, I can always do it. As Rob says, this can also be encoded in the policy.

It can, but I really don't see the reason for it. Can you give an example where operators defined for type T are not sensible to compact_optional?

I am trying to avoid the problem Boost.Optional (and std::experimental::optional) has, where it offers a mixed comparison between T and optional<T>. It is described in this post: https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/ Of course, because I provide no converting constructor, the mixed comparisons are removed... However, n this type I want be users to be very explicit about what they want, and it is not that obvious that they want to order the special value the same way as they would if they were using the raw type directly.

...

...

2. compact_optional does not provide direct assignment of the values of the stored type, requiring to manually construct a compact_optional-wrapped value. To me, this is too cumbersome to use while I don't see any wins from this restriction. Besides more typing, this essentially requires to use a typedef to declare and use the compact_optional variable.

Are you proposing a member function like opt.store_raw_value(v); ?

No, I was suggesting to allow assignment of values of type T (i.e. "opt = v;"). Having a named function like store_raw_value reduces the need in the typedef but the syntax should still be simpler.

You may object that this allows the assignment to make the opt object empty (or null, or singular - not sure what terminology you prefer). This may seem counterintuitive at first glance, but only as long as you treat the type as another flavor of optional<>, which is incorrect and is one reason why the name should be changed. What compact_optional really is is just a wrapper that allows to easily distinguish a special value of the governed object from all other values, and in that light there's nothing wrong if assigning this special value to the wrapper makes it singular. Analogously, there's nothing wrong with assigning a nullptr to a pointer.

In a way, this would mean and implicit conversion from T to compact_optional<T>. I do not want any kind of implicit conversion between the two (because the two are something different). I could offer: opt.raw_value() = some_T; Regards, &rzej