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]>
> > Hi Everyone, I would like to ask your opinion, suggestions, and perhaps
> > 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
> > invariants, by marking a bit pattern rather than any proper value of T
> > 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() ==
> > 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
> 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
Does that sound convincing?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk