Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)

2017-06-12 21:00 GMT+02:00 Gottlob Frege via Boost :

On Mon, Jun 12, 2017 at 1:29 PM, Peter Dimov via Boost wrote:

...

Gottlob Frege wrote:

...

On Wed, Jun 7, 2017 at 10:28 AM, Peter Dimov via Boost wrote:

...

Gottlob Frege wrote:

...

Agreed. But I don't see much value in the never-empty guarantee if

it

...

...

...

...

> doesn't give you the strong guarantee.

I'm not sure I understand this fully; could you please explain from what

...

expressions, and under what conditions, you expect the strong guarantee?

variant v1, v2; X x;

v1= v2; // do you expect strong guarantee here? v1 = std::move(v2); // here? v1 = x; // here? v1 = std::move(x); // here? v1.emplace<X>(); // here?

How about "all of the above"? At least when X and Y each offer the strong guarantee?

I'm interested in a practical answer, not a theoretically sound one which is of no use. Suppose that X is something that occurs in practice, such as std::vector, not some hypothetical X with a strong assignment, which doesn't.

Unless of course you only put types with strong assignment operators into your variants, which in practice confines you to built-ins, in which case all of the above will indeed be not just strong, but nonthrowing as well.

I think I'm going with Niall's comment some time earlier - to have variant give as strong a guarantee as the types it holds. If X = X (assignment) is only basic, I don't really need variant to somehow magically make variant<X> = variant<X> strong.

Maybe I just don't have enough time to think about this all the way through - your comments about how strong doesn't compose, and using the swap idiom at the correct level are interesting. Are you saying your variant2 fixes swap, but doesn't go full strong, and that that is all we really need?

First of all. I haven't seen anyone give an example where they need a strong guarantee for variant's assignment. There was one attempt with a state machine, but even there it seamed only theoretical. I think the questions if we can implement it are secondary to if anyone really needs it. If whoever has a real (as opposed to theoretical) need for a strong guarantee, please respond. Regards, &rzej;