Re: Empty boost::variant semantics (was Re: [boost] Re: Mini-review request: aligned_storage.hpp)

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-08 21:32:58

On Thursday 08 August 2002 06:11 pm, Eric Friedman wrote:
> OK, let me summarize variant's behavior as currently implemented in the
> sandbox:

Thank you!

[assignment can clear target]
[swap can clear either operand]

> // var2 is another variant, which may or may not be empty.
> var1 = var2;      // attempts to copy var2's held value
> var1.swap(var2);  // attempts to copy var2's held value; clears var2
>                   //   if successful

Hmmm. I'm not sure I like the copy and swap semantics. My lump of trouble 
tells me that giving more power to empty variants is dangerous, because users 
might begin to think that an empty variant is an okay thing to have. Really, 
it's an abomination that we'd like to destroy if we could. Just to bring back 
the singular iterator idea, remember that you can't do _anything_ with a 
singular iterator. You can't compare it, copy it anywhere, increment it, 
dereference it, etc. All you can do is replace it's value with something that 
is useful (dereferenceable or past-the-end). We might do well to follow that 
lead, and maybe even call the variant 'singular'.

I'd be happy if assignment from or a swap with an empty/singular variant 
either triggered an assertion or threw an exception.

> Note that visitation of an empty variant is an undefined operation! How
> nice it would be if variant could maintain the strong exception-safety
> guarantee...

Yes, it would be nice :(. 

> (Maybe section 3.8 of C++0x won't be so strict...)

Doubtful. Think about the confusion for a garbage collector if an object has 
two addresses at the same time :)

> Now I have some questions of my own:
>
> 1) Should variant::clear() become part of variant's public interface?
> That is, is the empty-variant concept somehow _useful_, or is it just an
> unfortunate necessary consequence of not having the strong guarantee?

I'd rather not have clear() in the variant interface, but that was probably 
obvious from my tirade against having any use for an empty variant :)

> 2) Is it OK to leave visitation of an empty variant undefined, or should
> it be well-defined to throw some particular kind of exception?

I'm happy with it being undefined.

> Sorry for the long message, but empty variant semantics complicate
> matters quite a bit!

Thanks for clearing this up. I had thought all of these empty-variant woes 
were behind us when we got the strong swap, but alas it was not so :(.

        Doug