To be honest, I like variant very much. I also like the valueless_by_exception concept - it is really, really good compromise. I might go as far as to say - it is not even a compromise. Neither a hidden empty sate nor expensive copy for complex objects are good things. valueless_by_exception is very good - if there is an exceptional event - you are in a exceptional state. Else - you use your types as usual, with zero overhead and never empty guarantee, like a normal "and" type. It is great.
Very silly to go stating first that variants are "simple" and inheritance is "complex", and after that going to slides were "simple" (sure, being very sarcastic on that) logic is shown how to access variant contents.
+David Sankel Outside Ivariant, is there any work to add native support for access of tuple and variant? Something to replace std::get(), which is cumbersome and awkward.
David Sankel I see, I am not sure, you keep an eye on isocpp.org forums, there is a suggestion about a possible syntax: goo.gl/EHGzE4. It will be nice to hear an educated opinion.
With boost::variant you have: 1) never empty guarantee; 2) support for recursion. While std::variant: 1) can be empty and you have to worry about it in every single function 2) no support for recursion. For now std::variant looks like another fiasco just like std::async and std::tuple.
With boost::variant you have an allocation for each assignment. For me, that's a sure thing to never use it in my code and cock up my own variant (pun intended). As for your points: 1) You're really nitpicking here. How many types do you use that throw on assignment? We're talking about exceptional cases, and you will *know* it will go into an empty state because you still need to catch the exception that is thrown by the assignment operator. In 99% of cases, you don't care about this empty state because you know that the types either can't throw or you'll have other things to worry about because an exception has been thrown. 2) I really think boost's method to support recursion is poorly designed. And as this presentation shows, you can still have recursion.
You've never used boost::variant ("never use it in my code") but somehow you have your opinion, thats interesting. "With boost::variant you have an allocation for each assignment" - this is wrong. It does not allocate on each assignment. Do you own research, gain some experience with boost::variant. 1) No, I'm not nitpicking. Most of my types do throw on assignment (just like std::vector does). "We're talking about exceptional..." - In other words, with boost::variant you have no problems with exceptions, now with std::variant you have to catch every single one to check that all of your std::variants are in valid state. Is there a proposal for std::scoped_anti_variant_fiasco to restore invariants? 2) I really think you have to share your bright ideas at www.boost.org, write an email, send a bug or pull request. After that try to answer this question - goo.gl/yYg9Og Not supporting recursion in std::variant is just silly.
"You've never used boost::variant ("never use it in my code") but somehow you have your opinion, thats interesting" Yes. Do you perhaps believe that you need to have used every possible permutation of a particular solution to have an opinion about the class of solutions in general? Of course I can have an opinion of not wanting an allocation on assignment, without having used a type that does that, because I know that heap allocations are costly (and this is from 15 years of practical experience in the games industry) "This is wrong. It does not allocate on each assignment. Do you own research, gain some experience with boost::variant." So you're saying that David Sankel is incorrect, including his slide at 19:00? If that is the case, then it is not so bad. And no disrespect, but somehow I find Mr. Sankel a bit more credible on the subject than some random youtuber. I will look into it, though. "now with std::variant you have to catch every single one to check that all of your std::variants are in valid state" Of course not. That seriously reeks of bad design. You don't put a try around the assignment itself, you need to catch it higher up. I am curious though, can you give an example of an exception thrown at assignment of a data type (not a container) that is not caused by programming error (or something disastrous like out of memory)? 2) I really don't see why the first piece of code in his answer is incorrect? Yes, he needs to change his algorithms because it doesn't follow his original pattern, but that's just a remnant for using an incompatible pattern in the first place. I don't think that every arbitrary type needs to be designed so it can be used as a drop-in replacement from a similar type from boost. Then why even move away from boost in the first pace? Boost has its merits, after all.
Please, let me summarize this. So, you have absolutely no idea of how boost::variant actually works, because you've spent your last 15 years in games industry. You want a random youtuber to explain you how OOM is not (and never been) "something disastrous". And you really do not understand that unique_ptr is not copy-constructible. Is that correct? Please, don't hurry with your answer, I'm okay if it will take you another 15 years. And, btw, "put a try around the assignment itself" - this is not what I'm saying. Please, try again.
To be honest, I like variant very much. I also like the valueless_by_exception concept - it is really, really good compromise. I might go as far as to say - it is not even a compromise. Neither a hidden empty sate nor expensive copy for complex objects are good things. valueless_by_exception is very good - if there is an exceptional event - you are in a exceptional state. Else - you use your types as usual, with zero overhead and never empty guarantee, like a normal "and" type. It is great.
Instead of `lvariant`, perhaps `costruct` since it is the categorical dual of the `struct`.?
I really like that colorscheme in the code... I wish I could use it in my day to day work!
The github.com/cppcon/cppcon2016 slides have some small lower quality differences.
Why not the auto keyword for catch-all matches?
Googles std::monostate, gets list of std and sti related articles. Appends C++ keyword, gets cppreference.com. Who names these things
Has "explicit union" be considered instrad of "enum union"?
Why not 'union class'?
It is modern version of union, much like enum class to enum.
it feels kinda like rustlangs enums, is it? so maybe the rust community has some experience it can share
Very silly to go stating first that variants are "simple" and inheritance is "complex", and after that going to slides were "simple" (sure, being very sarcastic on that) logic is shown how to access variant contents.
lvariant is a disgusting choice of keyword.
Agreed. It's a placeholder subject to bikeshedding.
The idea itself is amazing, don't get me wrong.
+David Sankel Outside Ivariant, is there any work to add native support for access of tuple and variant? Something to replace std::get(), which is cumbersome and awkward.
Михаил Найденов aside from pattern matching, not that I'm aware of.
David Sankel I see, I am not sure, you keep an eye on isocpp.org forums, there is a suggestion about a possible syntax: goo.gl/EHGzE4. It will be nice to hear an educated opinion.
With boost::variant you have: 1) never empty guarantee; 2) support for recursion. While std::variant: 1) can be empty and you have to worry about it in every single function 2) no support for recursion. For now std::variant looks like another fiasco just like std::async and std::tuple.
With boost::variant you have an allocation for each assignment. For me, that's a sure thing to never use it in my code and cock up my own variant (pun intended).
As for your points:
1) You're really nitpicking here. How many types do you use that throw on assignment? We're talking about exceptional cases, and you will *know* it will go into an empty state because you still need to catch the exception that is thrown by the assignment operator. In 99% of cases, you don't care about this empty state because you know that the types either can't throw or you'll have other things to worry about because an exception has been thrown.
2) I really think boost's method to support recursion is poorly designed. And as this presentation shows, you can still have recursion.
You've never used boost::variant ("never use it in my code") but somehow you have your opinion, thats interesting. "With boost::variant you have an allocation for each assignment" - this is wrong. It does not allocate on each assignment. Do you own research, gain some experience with boost::variant.
1) No, I'm not nitpicking. Most of my types do throw on assignment (just like std::vector does). "We're talking about exceptional..." - In other words, with boost::variant you have no problems with exceptions, now with std::variant you have to catch every single one to check that all of your std::variants are in valid state. Is there a proposal for std::scoped_anti_variant_fiasco to restore invariants?
2) I really think you have to share your bright ideas at www.boost.org, write an email, send a bug or pull request. After that try to answer this question - goo.gl/yYg9Og Not supporting recursion in std::variant is just silly.
"You've never used boost::variant ("never use it in my code") but somehow you have your opinion, thats interesting"
Yes. Do you perhaps believe that you need to have used every possible permutation of a particular solution to have an opinion about the class of solutions in general? Of course I can have an opinion of not wanting an allocation on assignment, without having used a type that does that, because I know that heap allocations are costly (and this is from 15 years of practical experience in the games industry)
"This is wrong. It does not allocate on each assignment. Do you own research, gain some experience with boost::variant."
So you're saying that David Sankel is incorrect, including his slide at 19:00? If that is the case, then it is not so bad. And no disrespect, but somehow I find Mr. Sankel a bit more credible on the subject than some random youtuber. I will look into it, though.
"now with std::variant you have to catch every single one to check that all of your std::variants are in valid state"
Of course not. That seriously reeks of bad design. You don't put a try around the assignment itself, you need to catch it higher up. I am curious though, can you give an example of an exception thrown at assignment of a data type (not a container) that is not caused by programming error (or something disastrous like out of memory)?
2) I really don't see why the first piece of code in his answer is incorrect? Yes, he needs to change his algorithms because it doesn't follow his original pattern, but that's just a remnant for using an incompatible pattern in the first place. I don't think that every arbitrary type needs to be designed so it can be used as a drop-in replacement from a similar type from boost. Then why even move away from boost in the first pace? Boost has its merits, after all.
Please, let me summarize this. So, you have absolutely no idea of how boost::variant actually works, because you've spent your last 15 years in games industry. You want a random youtuber to explain you how OOM is not (and never been) "something disastrous". And you really do not understand that unique_ptr is not copy-constructible. Is that correct? Please, don't hurry with your answer, I'm okay if it will take you another 15 years.
And, btw, "put a try around the assignment itself" - this is not what I'm saying. Please, try again.
Apparently this discussion is more about your ego than anything else.