C++ Logo

std-proposals

Advanced search

Re: std::as

From: Ryan P. Nicholl <rnicholl_at_[hidden]>
Date: Mon, 26 Oct 2020 20:59:52 +0000
The fact is that "get_if" does not actually compile to zero overhead abstraction atm on most compilers, nor would I want to only be able to get the zero overhead version by doing "-fno-null-references" because that excludes projects which contain legacy code from getting the optimization. Sure they should be fixed, but in general, it's not going to happen.

Also, though it'd be nice to have that optimization compiler side, you will still need to "git commit" to get the optimization, nobody is going to make such a flag default due to legacy code issues, so go ahead and edit your cmake files...

As far as conflicts when doing "using namespace std;" due to new symbols being added to std::, I feel like that's a risk you're explicitly opting into when "using namespace X;".

I would still prefer std::as over std::get_unchecked though, because I don't think you should have to explicitly opt-in to zero overhead behavior. The difference is philosophical though, calling it "get_unchecked" accomplishes the same purpose with no runtime overhead. I don't really want to be typing "unsafe"/"unchecked" everywhere, that's for C# programmers. :)

--
Ryan P. Nicholl
Tel: (678)-358-7765
Personal Email: rnicholl_at_[hidden]
Work Email: ryan.nicholl_at_[hidden]rosoft.com
Tox: 52B3A61CDAF88BCC854F568933F071E3530600CDBA3D5354AADC9AD179575D68021AE959719D
-------- Original Message --------
On Oct 26, 2020, 15:17, Arthur O'Dwyer wrote:
> 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

Received on 2020-10-26 16:00:07