Re: [boost] markable -- informal review request

2016-09-21 18:35 GMT+02:00 Niall Douglas :

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

...

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), "");

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) == sizeof(bool); sizeof(markable>) == 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 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 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