Re: [boost] markable -- informal review request

Subject: Re: [boost] markable -- informal review request
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-09-20 07:03:32

2016-09-20 11:12 GMT+02:00 Klaim - Joël Lamotte <mjklaim_at_[hidden]>:

> On 16 September 2016 at 15:23, Andrzej Krzemienski <akrzemi1_at_[hidden]>
> 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<mark_int<int, -1>> 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;