On Tue, Oct 27, 2020 at 11:43 AM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On Tue, Oct 27, 2020 at 6:16 AM Miguel Ojeda via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > On Mon, Oct 26, 2020 at 8:18 PM Arthur O'Dwyer via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> > >
> > > However, I would still !vote against such a proposal, because the fact remains that `*std::get_if<int>(&v)` has the same normative effect, and is shorter to type, and is idiomatic C++17 already. I don't think C++23 needs a new idiom to sit alongside the existing C++17 idiom. In particular, I want to be able to keep using `*std::get_if<int>(&v)` in my C++17 and C++20 codebases and get the optimization, without needing to rewrite any code. If the optimization is available only to C++23 codebases, and if I have to make a `git commit` touching the code before the compiler will deign to optimize it, that's not so useful to me.
> >
> > Simple and proper APIs that reflect the proper intention of the writer
> > are better than "idioms" which are only so because the library did not
> > include a function to start with. Not to mention that optimizers are
> > not magical, plus it takes build time to untangle the mess anyway.
>
> But isn't that what `get_if` does already? It is a simple API, and a
> proper one. It reflects the intent of the writer. It's not an idiom;
> it's how you get a value from a `variant`.

Even though I suggested it in a reply above, *get_if is a pretty ugly
way to get a value out of a variant.
The intent of get_if is that you will handle the null case.
The intent of *get_if is that you won't.

That's not making intent clear.

-- 
Be seeing you,
Tony