Re: [boost] markable -- informal review request

Subject: Re: [boost] markable -- informal review request
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2016-09-24 08:54:26

2016-09-21 18:35 GMT+02:00 Niall Douglas <s_sourceforge_at_[hidden]>:

> On 16 Sep 2016 at 15:23, Andrzej Krzemienski wrote:
>
> > 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), "");
>
> I'm not sure about the value add of this simplified optional
> implementation. What compelling use cases does it have over optional?
>

Compared to optional:

1. no spacial overhead for storing "initialized" flag:
sizeof(markable<mark_bool>) == sizeof(bool);
sizeof(markable<mark_int<int, -1>>) == sizeof(int);

2. More type safe: no implicit conversions; also built-in opaque
typedef-like tool for generating similar, but not interchangable types

3. The ability to "remove certain values of T.
Suppose you want to return a std::string, but you want to signal to the
callers (by the means of type-system) that they should treat an empty
string in a non-uniform way. If you do it with optional<string>, you get
this useless state:

bool useless_state(optional<string> os)
{
  return os != boost::none && os->empty();
}

With markable, when you treat empty string as "empty" markable, you are
guaranteed that the contained string is never empty:

void guarantee(markable<mark_stl_empty<string>> os)
{
  if (os.has_value())
    assert (!os.value().empty());
}

In my own boost::outcome::option<T>, it's just one of many
> specialisations of basic_monad<T, EC, E> and has all the advantages
> of being a basic_monad, including implicit convertibility to more
> expressive basic_monad's, monadic operators etc. It also has the same
> ridiculous optimisability that basic_monad has and typically reduces
> down to no runtime overhead (which from inspection so does your
> markable).
>
> Yours does have likely very low impact on compile times though. Mine
> does stress the optimiser in release builds a lot.
>

Compared to boost::outcome::option?

I do not know boost::outcome::option that well? Are its characteristics
documented anywhere?

Thank you for response,
&rzej