On 1 Jul 2015 at 21:07, charleyb123 . wrote:
So, after having looked hard for alternatives, I actually like your syntax (because I have a hard time finding a more obvious way to do that with if/else).
I ended up a similar place of not being able to think of anything better than meets the criteria.
But, I also agree with other comments in this thread that it annoys most programmers to demand explicit-comparison-testing-with-bool. We expect implicit-bool-conversion, and frankly, it is quite awkward to do a three-way-division using a boolean if/else construct.
Ah, I suppose I didn't mention my solution to that yet. My tribool won't convert implicitly to bool, but anything converting to a tribool also converts to a bool. So, for monad<T>: //! \brief Same as `true_(tribool(*this))` constexpr explicit operator bool() const noexcept; //! \brief True if monad contains a value_type, false if monad is empty, else unknown. constexpr operator tribool::tribool() const noexcept; So, if we have: monad<int> a; We can do via the explicit bool conversion: if(a) { execute if a has value } if(!a) { execute if a does not have value i.e. is empty or errored/excepted } This is natural to program against. But if we want the ternary logic we can also do: if(true_(a)) { execute if a has value } if(false_(a)) { execute if a is empty } if(unknown(a)) { execute if a is errored/excepted } This is another appeal of the free function based ternary logic design. You push the implicit bool conversion onto the thing with tribool state. The library user gets both boolean and ternary idioms according to their wont. Does this appeal to the list more? I realise I didn't explain myself well. As usual.
I *really* like that you are pursuing it, though. Like pornography, we should mostly be able to recognize elegance and expressiveness when somebody demonstrates an elegant way to do it.
I have noticed that extremely few find my code nor design elegant nor expressive :) We'll see during the AFIO review in two weeks. My main goal between now and then is to use these monadic futures to make the AFIO API much more conventional than at present, so I'm hoping to hammer down a whole load of unexpected rough edges for the conventional Boost community member. I'm hoping that will be enough to get it passed review and into Boost. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/