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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-02 16:48:39

2017-06-02 18:42 GMT+02:00 Robert Ramey via Boost <boost_at_[hidden]>:

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

In this spirit, I have got a question to Niall, or whoever who used the
library in their real projects: did the use cases required to change the
state of a once constructed `outcome`?

Regards,
&rzej;