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

On 6/2/17 8:53 AM, Andrzej Krzemienski via Boost wrote:

2017-06-02 17:17 GMT+02:00 Robert Ramey via Boost :

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