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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-02 16:42:48

On 6/2/17 8:53 AM, Andrzej Krzemienski via Boost wrote:
> 2017-06-02 17:17 GMT+02:00 Robert Ramey via Boost <boost_at_[hidden]>:

> 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.

That is exactly what I'm questioning.  I'm suggesting that changing the 
value of a "result" is indication of a fundamental mis-understanding 
what a "result" is.  I'm suggesting that requiring that "expected" be 
immutable will actually improve it's conceptual power for users.  It 
require them to use a more suitable type when "expected" is not 
suitable. Of course I'm guilty of speculating myself here.  I'm 
questioning the premise "component X is useful, but it would be more 
useful if ....".  Maybe we should keep simple things simple.

BTW TL;DR; - I'm coming to the opinion that the usage of immutable 
objects is a key attribute of the functional programming ala haskel and 
that perhaps we should think about this more when we design stuff.

> Also, some use cases require being able to store outcomes in container

LOL - I can't prove it, but this sounds like a very bad idea to me.  But 
it also raises an entirely different issue.  The requirement of default 
constructors for container elements is an artifact of the way containers 
are implemented.  So here, an implementation artifact is bleeding over 
to the abstract conceptual design of the element.  This is recipe for 
brain soup.

> I guess design would be easier if we could see all use cases listed.

Ahhh - the pitfalls when designing on speculation about the future.  Mix 
in design by committee and you've got ... gridlock.

The discussions are interesting, but when they evolve into communal 
design from a simple review things get ... complicated.  Maybe if we 
kept reviews more focused on thumbs up/down and criticism and support 
rather than "design" they might be less of a death march and we might 
encourage more people to participate in reviews.

Robert Ramey