These are chat archives for boostorg/hana

27th
Aug 2016
Jason Rice
@ricejasonf
Aug 27 2016 04:14
Would it just fail to compile if you did 'get<2>'?
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 06:48
In constexpr? Yes it gets into the branch with a throw so the comstexpr is invalid.
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 08:17

So if you write this:

constexpr variant<int, char> v = 'C';
constexpr int i = get<0>(v);
constexpr int j = get<int>(v);

It will give a compile-error at compile time; but it will throw an exception at runtime.

Louis Dionne
@ldionne
Aug 27 2016 17:50
A constexpr variant is a nice utility, but I don’t think it makes much sense for Hana. Here’s why: If a variant was to be included in Hana, it would have to know what type it contains (out of the N possible variants) at compile-time, just like hana::optional knows whether it is empty or not at compile-time. And by compile-time, I really mean that the information is encoded in the type of the variant, not only that the variant can be used inside a constant expression.
However, a variant that knows which type it contains is pretty much equivalent to the type it contains itself, see what I mean?
So such a construct in Hana-world is not too useful, at least from what I can see so far. In fact, Hana contained a hana::either at some point (which is really just a binary variant), but it was removed precisely for this reason.
That being said, a constexpr variant probably makes a lot of sense in the context of a constexpr-enabled standard library, such as Sprout.
And in fact they already seem to have a constexpr variant, but I don’t quite understand the implementation (it seems to be based on tuple, not union, which is strange).
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 21:24
Yeah, I guessed that. Actually the only application for a constexpr variant I could think of, was to limit the types you could use with a particular functions. Since Concepts will come eventually, this would be a misguided attempt.
Louis Dionne
@ldionne
Aug 27 2016 21:29
Well, I sure think it could be useful if you need to use the variant in a generic algorithm that you want to make constexpr.
And there are probably many other use cases.
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 21:39
Ok, wenn then it could maybe be a successor to boost.variant. I'll annoy the boost mailing lists then
Louis Dionne
@ldionne
Aug 27 2016 21:52
Then again, boost::variant aims to be a more general purpose variant from what I understand, and I don’t know whether it’s possible to make its implementation constexpr. Are there significant differences between your variant and e.g. std::variant besides constexpr-friendliness?
If not, then I’m sure the wider C++ community would actually jump on this implementation.
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 22:16
Not really, it might implement more conversions etc.
i.e. an implicit conversion like that:
variant<int, char> v = 42;
variant<int, char, double> v2 = v;
But the whole constexpr stuff changes the implementation of the storage rather intensively, so I am not sure if that actually makes that much sense.
Klemens Morgenstern
@klemens-morgenstern
Aug 27 2016 22:22
I.e. I might want to implement a version of std::variant and push what it can do - starting with constexpr :smile:
Louis Dionne
@ldionne
Aug 27 2016 22:54
Alright. In any case, feel free to keep us here updated on how that goes. @mpark Haven’t you also implemented a constexpr variant at some point?