Subject: [boost] [outcome] expected, etc. why are these assignable
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-02 15:17:39
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(...);
void function(checked_result & cr, ....) will be the same
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk