Re: [boost] markable -- informal review request

2016-09-20 11:12 GMT+02:00 Klaim - Joël Lamotte :

On 16 September 2016 at 15:23, Andrzej Krzemienski wrote:

...

Hi Everyone, I would like to ask your opinion, suggestions, and perhaps an informal review of the 'markable' library. An alternative to boost::optional when performance really matters. It is the second incarnation of the 'compact_optional' library that I have presented last year.

The main differences from the previous version: * name change: it is called 'markable' so that it is not confused with 'optional'. It uses "mark values" and mark policies" * it has the ability to mark an empty state even for the types with strong invariants, by marking a bit pattern rather than any proper value of T (an idea by Matt Calabrese)

An example use case:

typedef markable> opt_int;

opt_int oi; opt_int o2 (2); assert (!oi.has_value());assert (o2.has_value());assert (o2.value() == 2); static_assert (sizeof(opt_int) == sizeof(int), "");

The github repository: https://github.com/akrzemi1/markable And documentation therein: https://github.com/akrzemi1/markable/tree/master/documentation

Any comments, suggestions or critique are most welcome.

Regards, &rzej;

I am interested in doing a quick review of this library, but I have first to ask why "markable"? I'm not sure I understand the intended meaning of this word in this context.

Joël Lamotte

Hi Joël, Thank you for expressing your interest. You bring up a good point. The docs lack rationale for the naming. I will try to update them soon.

The reason is somewhat psychological or "social"; and at the bottom boils down to the fact that the compromise around std::optional in The Standards Committee is very fragile, and decisions around `markable` may affect it. Clearly, there is some overlap between `optional` (boost::optional, std::optional) and `markable`. I was explicitly requested to remove any 'optional' from this library's name, in order not to make any suggestion that I am competing with `optional` or that I am offering a superior alternative -- I am not. You can look at my library from two perspectives: 1. I am giving you a more efficient alternative to optional<int>, at the cost of compromising the interface. 2. It is just an `int` with some magical value, say -1, but I am making it more explicit that this `-1` marks a special case. In this second sense, "mark", "markable", "marked" quite naturally reflect the fact that I am marking one value as special, which is the core idea behind this library. One could consider other alternatives like "magic_val", but they are not much better, and do not transform into adjectives and verbs that easily ("magic_valued"?). Does that sound convincing? Regards, &rzej;