2017-06-02 17:17 GMT+02:00 Robert Ramey via Boost
It just occurred to me that for a similar component I created some time ago for my own purposes, I (intentionally?) support of the assignment operator. Copy construction was permitted however. So the only way to use the component is:
checked_result<int> = function(...);
something
void function(checked_result & cr, ....) will be the same
as
void function(const checked_result & cr, ...)
because checked_result only contains const functions. That is, once constructed, it's immutable.
Personally I never use an interface which passes a mutable type to a function. To me it violates the mathematical idea of what a function is.
Doesn't this simplify things? Doesn't this eliminate the whole questions about about empty state, etc. Doesn't this better model the "mondad" concept we're trying to leverage on. And why the hell are we modifying and an object designed to model a result in the first place? It doesn't make logical sense in terms of we expect a "result" to be. I plunk down my money (a function) and ask for a pepperoni pizza. Either they say they don't have pepperoni and give me my money back or give me a pizza. I don't think of modifying this result - it's an artifact of history. And wouldn't making these things immutable, eliminate a large part of the whole controversy?
Just a thought. I think sometimes something is hard because we haven't thought enough about what we're really trying to do - what problem we're trying to solve.
The consumer of the `outcome` could just observe the state. But the producer may have legitimate reasons to change the value of `outcome` objects when preparing its final value. Also, some use cases require being able to store outcomes in containers. I guess design would be easier if we could see all use cases listed. Regards, &rzej;