Is there any practical reason why std::get_if (std::variant) takes a variant argument by pointer instead of by value/&/const&?

Question

I've never used std::get_if, and since its name is different from std::get, I don't see a reason why its argument should be a pointer¹ (whereas std::get has a by-reference parameter).

¹If it was named std::get too, then overload resolution would be a reason enough.

Yes, my question could be duped to the question Is it absolutely necessary for std::any_cast() and std::get_if(std::variant) to take pointer as an argument?, but the point is that there's no answer there that addresses std::get_if vs std::get, just one comment; the only answer concentrates on std::any_cast.

I seem to recall Jason Turner talking about why that is in one of the C++ Weekly videos. — WBuck, Sep 21 '21 at 14:45
Does this answer your question? [Is it absolutely necessary for std::any\_cast() and std::get\_if(std::variant) to take pointer as an argument?](https://stackoverflow.com/questions/38617907/is-it-absolutely-necessary-for-stdany-cast-and-stdget-ifstdvariant-to) — xskxzr, Sep 22 '21 at 03:29

康桓瑋 · Accepted Answer · 2021-09-22T04:52:28.333

15

This is because get_if is noexcept, so an exception will never be thrown. In order to achieve this, it must return a pointer so that nullptr can be returned when the access fails.

Because it returned the pointer, it must take the pointer of the variant. If it takes the reference of variant, then it must be able to accept the type of variant&, const variant&, variant&& and const variant&&, but it does not make sense for the pointer to remain ref-qualified.

Considering that get_if accepts variant&&, what you do is return the address of an xvalue, which is terrible. Even if get_if only allows variant& and const variant&, the latter can still accept a variant&& and return a dangling.

edited Sep 22 '21 at 04:52

answered Sep 22 '21 at 04:28

康桓瑋

33,481
5
40
90

I truly don't understand the explanation in the second paragraph. – Enlico Sep 22 '21 at 04:30
1

@Enlico. Assuming `get_if` accepts references, what type should it return when it accepts `variant&&`? – 康桓瑋 Sep 22 '21 at 04:33
`variant&&` would bind only to rvalues, right? Then wouldn't returning a `nullptr` be the right choice? – Enlico Sep 22 '21 at 05:06
2

@Enlico. That can be a choice, but it also means that `get_if(std::move(v))` will return a `nullptr` even if there is no problem returning its address. – 康桓瑋 Sep 22 '21 at 05:17
It's just like `unique_ptr.get()` I don't see the reason it's any more invalid for `variant`. – apple apple Sep 22 '21 at 19:38
2

The `variant &&` issue can be easily resolved with an `= delete` overload, if necessary. – David Stone Feb 18 '22 at 20:52

score 4 · Answer 2 · answered Sep 21 '21 at 14:45

From what I can tell, it is based off dynamic cast logic. The dynamic cast that can fail takes a pointer and returns a pointer.

Similarly, get that can fail takes a pointer and returns one.

But really it looks like a tiny bikeshed decision of not much importance.

score 1 · Answer 3 · edited Mar 09 '23 at 13:27

1

This design allows you to apply "chained" invocations like this:

struct A : public std::variant<int, float>{};

int main()
{
    std::variant<A, char> f;
    A a;
    static_cast<std::variant<int, float>&>(a) = 10;
    f = a;
    cout << *std::get_if<int>(std::get_if<A>(&f));
    return 0;
}

edited Mar 09 '23 at 13:27

Eric Aya

69,473
35
181
253

answered Mar 09 '23 at 13:24

Alex Aparin

4,393
5
25
51

Is there any practical reason why std::get_if (std::variant) takes a variant argument by pointer instead of by value/&/const&?

3 Answers3