Mickey Rose

D'oh! GCC 4.7 doesn't fail to substitute `decltype(void(declval()()))` when `F` doesn't have `operator()()`, and then wants to call it... :boom: No idea how to fix that atm

> Ideally would be nice not to require writingno-op` code at all. Yes, that is possible if `R` (the return type inferred from the `first_type`) is default-constructible. It's hard to...

This may sound like heresy, as `sizeof...(Ts)` returns a `size_t`, but if instance size is a concern, having `size_t type_index` seems wasteful. For most practical uses, `uint8_t` would be enough;...

I've found similar index-type shrinking in [anthonyw's implementation](https://bitbucket.org/anthonyw/variant/src/932fe16799f1/variant?fileviewer=file-view-default#variant-140), and a coarser one is optional in boost (BOOST_VARIANT_MINIMIZE_SIZE)

I think `uint8_t` is fine. At least on x86-64, an operand size prefix is only needed for int16 and int64 (=> longer instructions => longer code => caches not happy),...

Yes, should be ``` c++ noexcept(noexcept(variant(std::forward(rhs))) && std::is_move_constructible::value) ``` The first part covers `is_constructible && is_destructible`. Edit: assignable->constructible, as helper::move calls constructor. It'd probably be best to dispatch on rvalue-ness...

In that case, just remove both conversion-assignment operators, they're not needed -- actually the compiler will generate exactly the code in the first, and better than the second: ``` c++...

:+1: - and as for throwing destructors, they're such a dark matter that I probably shouldn't have added any `noexcept(something complex)` to variant destructor in the first place. Just require...

Can we revisit this, please? One of the concerns raised against `unique_ptr` was performance. Where is this coming from? I don't see any operations in `recursive_wrapper` that would be slower...

> // Somewhere later, a is passed into a function As it stands, the moved-from state is not documented, so it could be anything. I agree that a "broken" state...