call visitor with no argument if variant is uninitialized

[lightmare]

If called on uninitialized variant, apply_visitor leads to dispatcher calling get<T> with the last alternative type, which throws.

This PR changes the behaviour so that the dispatcher either

• throws with more helpful message "apply_visitor on uninitialized variant", or
• calls the visitor with no arguments, if that is possible

I also considered default-constructing the result type, instead of throwing, if the visitor cannot be called with no argument. That could work in some cases (e.g. when visitor extracts some value and default-constructed is okay; or when it applies some transformation and returns void), but could be very surprising in others, so I didn't include this "feature".

[springmeyer]

/cc @artemp @joto

[lightmare]

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

[springmeyer]

GCC 4.7 is not a critical compiler to support. I've been wondering if we should drop support for it. Because its c++11 support is pretty marginal anyway.

[artemp]

@lightmare - I like the general idea around 'no_init, thanks! Ideally would be nice not to require writingno-op` code at all. I'll review in over coming days and maybe we'll do a point release ? /cc @springmeyer @joto

[lightmare]

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 imagine real usage that would rely on the visitor either being called with a value, or exception thrown.

A contrived example could be made from the unit test. auto a = 12345 / apply_visitor(total_size(), v) -- currently this throws bad_variant_access if v is uninitialized. If we default-constructed the result, it would divide by zero.