[boost] [outcome] expected, etc. why are these assignable

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(...);

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.

Robert Ramey