On Fri, Nov 6, 2020 at 10:11 AM Tony V E <tvaneerd_at_[hidden]> wrote:

>
> The other problem is that variant shouldn't have used std::get at all.
> std::get, originally for tuple/pair, never throws - it is statically
> known. It is a fundamentally different function than std::get on
> variant. They shouldn't have the same name.
>

Here we agree. If I were designing `tuple` and `variant` from scratch, I
would:
- Give `tuple` a `.get` member function template, as in, `mytuple.get<1>()`
and `mytuple.get<int>()`.
- Also give `tuple` a `.get` member function template, as in,
`mytuple.get(std::index_constant<1>())`.
- Give `variant` a `.value` member function template, as in,
`myvariant.value<1>()` and `myvariant.value<int>()`.
- Also give `variant` a `.value` member function template, as in,
`myvariant.value(std::index_constant<1>())`.

...and yet, this still doesn't move toward a naming solution for OP's
"unchecked_get". We can give `variant` checked and unchecked versions of
the getter, by analogy to `optional`... but `optional` is able to use
`operator*` for the unchecked version, whereas `variant` can't, because
the function needs to take a parameter. The obvious extension would be
- Also give `variant` an unchecked `operator[]` member function template,
as in, `myvariant[std::index_constant<1>()]`.
but there's no obvious way to extend that to types (reuse
`std::in_place_type_t`?), and also it's not as ergonomic as the existing
solution of just making a `get_if` function that returns a pointer.

–Arthur