Boost logo

Boost :

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`?


Boost list run by bdawes at, gregod at, cpdaniel at, john at