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

Subject: Re: [boost] variant2 never empty guarantees (was: Re: Outcome/expected/etc/etc/etc)
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-13 15:22:49

First theoretical, then more real-ish:

I have a drawing program that draws rectangles, circles, triangles.  I
want to change a circle to a triangle.  The user expects it to work,
or a reason why it failed.  They don't want the circle to become a
rectangle.

More realistic, but exactly the same:

In my codebase of projection mapping (multiple projectors projecting a
seamless image onto a surface) we have different screen types - flat,
cylinder, spherical, and custom (mesh file).  Each type comes with a
bunch of settings, so it isn't just a enum, each is a separate type.
The user can select which they want from a drop-down.

This is currently _not_ using a variant, but I think it should.
However, when the user switches from cylinder to "custom" and the mesh
is invalid or out of memory, etc, I don't want the cylinder to turn
into a flat screen.

I haven't coded it yet, but I think it will come down to a strong
assignment guarantee (or I handle it myself elsewhere).

Tony

On Tue, Jun 13, 2017 at 3:31 AM, Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> 2017-06-12 21:00 GMT+02:00 Gottlob Frege via Boost <boost_at_[hidden]>:
>
>> On Mon, Jun 12, 2017 at 1:29 PM, Peter Dimov via Boost
>> <boost_at_[hidden]> wrote:
>> > Gottlob Frege wrote:
>> >>
>> >> On Wed, Jun 7, 2017 at 10:28 AM, Peter Dimov via Boost
>> >> <boost_at_[hidden]> 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<X, Y> 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;
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost