C++17 feature proposal: Allow if constexpr()

119 views
Skip to first unread message

Jayson Adams

unread,
Jan 6, 2022, 4:05:50 PM1/6/22
to c...@chromium.org
Hello,

I was looking through the codebase today and happened to run across the following comment in checked_math_impl.h:

// TODO(jschuh) Make this "constexpr if" once we're C++17.

This seems like a reasonable thing to do here but I actually don't have strong feelings about it. From a codebase hygiene standpoint, now that C++17 is available I'd like to move forward with this TODO or remove it. Making a decision to allow or ban if constexpr() is the first step.

Best,

__jayson

Avi Drissman

unread,
Jan 6, 2022, 4:22:14 PM1/6/22
to Jayson Adams, cxx
+1 for this; this would be a strict improvement.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAC2KseO8z7JUbjpM_avE0je01x7s_jG%3D--r_Xq1sVBBoAtupxA%40mail.gmail.com.

Jeremy Roman

unread,
Jan 6, 2022, 4:27:08 PM1/6/22
to Avi Drissman, Jayson Adams, cxx
Strictly speaking we would also need to wrap the remainder of the function in an else branch (contrary to common style recommendations to the contrary), since the rules don't discard statements due to early-return AFAIK. Right?

Peter Kasting

unread,
Jan 6, 2022, 4:43:06 PM1/6/22
to Jayson Adams, cxx
I was about to write this proposal since I have a local cl using constexpr if here and in a few other places :)

+1

PK

Peter Kasting

unread,
Jan 6, 2022, 5:33:59 PM1/6/22
to Jeremy Roman, Avi Drissman, Jayson Adams, cxx
On Thu, Jan 6, 2022 at 1:27 PM Jeremy Roman <jbr...@chromium.org> wrote:
Strictly speaking we would also need to wrap the remainder of the function in an else branch (contrary to common style recommendations to the contrary), since the rules don't discard statements due to early-return AFAIK. Right?

At least in this case, wrapping the remaining function in "else" has no effect on the generated code size.

PK 

Jeremy Roman

unread,
Jan 6, 2022, 5:48:25 PM1/6/22
to Peter Kasting, Avi Drissman, Jayson Adams, cxx
Personally I'm looking forward to cleaning up stuff like this.

Jayson Adams

unread,
Jan 6, 2022, 6:37:02 PM1/6/22
to Jeremy Roman, Peter Kasting, Avi Drissman, cxx
3370526: [c++17] Add "if constexpr" to the allowed C++17 feature list | https://chromium-review.googlesource.com/c/chromium/src/+/3370526

Roland Bock

unread,
Jan 7, 2022, 12:42:15 AM1/7/22
to Jayson Adams, Jeremy Roman, Peter Kasting, Avi Drissman, cxx
+1 

"if constexpr" can make a massive difference in readability of C++ template code.

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.

Jayson Adams

unread,
Jan 11, 2022, 12:00:31 PM1/11/22
to Roland Bock, Jeremy Roman, Peter Kasting, Avi Drissman, cxx
The change has landed.

Victor Vianna

unread,
Jan 13, 2022, 2:18:52 PM1/13/22
to cxx, Jayson Adams, Jeremy Roman, Peter Kasting, Avi Drissman, cxx, rb...@google.com
Curious: what's the guidance on using this new feature vs ifdefs? It seems like it could fundamentally replace ifdefs. If so, do we intend to migrate things like the very common "#if defined(OS_FOO)"?

Jeremy Roman

unread,
Jan 13, 2022, 3:30:51 PM1/13/22
to Victor Vianna, cxx, Jayson Adams, Peter Kasting, Avi Drissman, rb...@google.com
I wouldn't expect it to significantly displace #if, because it only works in certain contexts. I think it's more often going to be a replacement for using additional layers of templated functions/structs to avoid compiler errors.
Reply all
Reply to author
Forward
0 new messages