On Tue, Dec 10, 2013 at 8:36 AM, Matt Calabrese
On Mon, Dec 9, 2013 at 12:28 PM, Peter Dimov
wrote: Steven Watanabe wrote:
The difference between tuple<> and variant<> is that tuple<> has exactly one possible value, but variant<> has no possible values.
Not conceptually. tuple
is struct { X x; Y y; }. variant is union { X x; Y y; }. tuple<> is struct {}. variant<> is union {}. All are valid. It's not that important though. The current variant doesn't support this case, so there's not much reason for the variadic one to do so. Sorry for bringing it up.
I'm going to have to back you up here that a variant<> does sometimes make sense and I don't think we'd lose anything by supporting it. In real, non-hypohetical code, I've encountered a place where I had a 0-element variant come up and had to special-case my code so that it would work as expected. The way it came up was I had a variant of several types (the type list was the result of some metaprogramming) and a visitor of that variant that returned the result of a member function call on the currently stored object, whichever one it was (each type in the variant had the same named function but the return type wasn't necessarily the same). I constructed the return type based on the return types of the functions in question, eliminating any duplicates. If one of the functions returned a void type, no type was added to the list. I stored this result and later on did things with it (such as display it).
I think that case would better be handled by variant<blank>. I.e. you can replace void return types with blank and the rest of the code can be left intact.