On Mon, Oct 26, 2020 at 2:09 PM Ryan P. Nicholl <rnicholl_at_[hidden]>
wrote:

> I mean sure, we could convince compiler writers to implement more
> optimizations... or we could just add std::as. We currently require a
> branch even if it could theoretically be removed by the optimizer. Both get
> and get_if require a branch. I would not rely on compilers eliminating
> branches. My experience is that they are quite poor at doing this.
>

I disagree in this case. But I'd agree in some cases; I don't think your
argument is completely invalid.
But then your `std::as` proposal still has two problems that need solving
via bikeshedding:
- You cannot use the name `as` because it's too short; I guarantee somebody
out there has a list of A objects named `as` (and is also `using namespace
std`).
- You should not use the name `as` because it's literally shorter than the
"checked" version `std::get`. The "unsafe" version should be something long
and scary-looking, that newbies can't start using by accident.

I would suggest you propose `std::get_unchecked<int>(v)`.

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.

–Arthur