C++ Logo


Advanced search

Subject: Re: [std-proposals] std::as
From: Christof Franke (cfranke_at_[hidden])
Date: 2020-11-06 10:47:31

IMHO there is no need for any change to std::variant.


If you use std::get after a check with std::holds_alternative, the compiler will most probably optimize the second check away. Like in


void printValue(std::variant<int, double> value) {

    if (std::holds_alternative<int>(value)) {

        std::cout << std::get<int>(value)

    } else if (std::holds_alternative<double>(value) {

       std::cout << std::get<double>(value);




I have tested GCC, clang, and MSVC. They all remove any double-checks and exception code during optimization.


In case you want to call a function with a std::variant as parameter of which the alternative held by the variant is known, why do you pass the variant instead of the value held?





Von: Std-Proposals <std-proposals-bounces_at_[hidden]> Im Auftrag von Arthur O'Dwyer via Std-Proposals
Gesendet: Donnerstag, 5. November 2020 21:53
An: Std-Proposals <std-proposals_at_[hidden]>
Cc: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Betreff: Re: [std-proposals] std::as


On Thu, Nov 5, 2020 at 12:09 PM Avi Kivity via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:

How can the reader of *get_if() tell if the author intended this optimization, or was just lazy?

Well, we know what semantics they intended -- "get the value if possible; otherwise UB." Whether they get the optimization is up to the vendor (but vendors should make the performant choice, please).


Function names should communicate intent. "get_if()" communicates that you don't know if the variant holds the the type you are asking for or not.

No it doesn't -- I mean, not a priori. The identifier `get_if` is completely meaningless a priori -- just like std::get and std::visit. The only way for a programmer to learn what these identifiers mean is to, well, learn. (I have a Back to Basics talk on algebraic data types I can recommend!) Once the programmer has learned the idioms around std::variant, they'll know what *std::get_if "communicates," by definition, because *std::get_if is one of the idioms around std::variant.


Of course, if the maintainer(s) of some particular codebase decide that they'd like another name for this operation, they can write a named function:


Target uncheckedGetTarget(const std::variant<Target, Destination>& td) {

    MC_ASSERT(td.index() == 0);

    return *std::get_if<0>(&td);



I don't think the standard library ought to bother providing any "middle ground" between the existing C++17 idiom *std::get_if and the codebase-specific uncheckedGetTarget.



STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups