C++14 versions of C++17 bits in base/template_util.h

13 views
Skip to first unread message

Lei Zhang

unread,
Apr 21, 2022, 7:54:50 PMApr 21
to cxx
base/template_util.h has C++14 versions of various C++17 bits, e.g.
base::void_t base::bool_constant, etc. Are there any concerns about
switching from these to their std:: counterparts?

Jeremy Roman

unread,
Apr 21, 2022, 9:47:21 PMApr 21
to Lei Zhang, cxx
This seems like a good change to me.

--
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/CACSHbcTkPpEOPmnTGeweqSCDb-AOWBmvWAqwuZ5ahcA5%3DxP6zg%40mail.gmail.com.

dan...@chromium.org

unread,
Apr 22, 2022, 9:18:54 AMApr 22
to Jeremy Roman, Lei Zhang, cxx

Lei Zhang

unread,
Apr 26, 2022, 4:01:19 PMApr 26
to dan...@chromium.org, Jeremy Roman, cxx
Filed crbug.com/1320019 for this.

Avi Drissman

unread,
Apr 27, 2022, 1:24:48 PMApr 27
to Lei Zhang, Dana Jansens, Jeremy Roman, cxx
I'm poking at this and some of these aren't officially allowed in the Features doc. Are any of:

std::void_t
std::in_place_t
std::in_place_type_t
std::bool_constant
std::conjunction
std::disjunction
std::negation
std::invoke_result
std::is_invocable_r
std::is_invocable

controversial? Should I move them to the allowed section as I go, or should I file each as a request here on cxx@?

K. Moon

unread,
Apr 27, 2022, 1:27:57 PMApr 27
to Avi Drissman, Lei Zhang, Dana Jansens, Jeremy Roman, cxx
My personal blanket take is that if they're already allowed in their //base (or //third_party/abseil-cpp, for that matter) form, then they're not controversial.

Peter Kasting

unread,
Apr 27, 2022, 1:32:29 PMApr 27
to Avi Drissman, Lei Zhang, Dana Jansens, Jeremy Roman, cxx
On Wed, Apr 27, 2022 at 10:24 AM 'Avi Drissman' via cxx <c...@chromium.org> wrote:
I'm poking at this and some of these aren't officially allowed in the Features doc. Are any of:

std::void_t
std::in_place_t
std::in_place_type_t
std::bool_constant
std::conjunction
std::disjunction
std::negation
std::invoke_result
std::is_invocable_r
std::is_invocable

controversial? Should I move them to the allowed section as I go, or should I file each as a request here on cxx@?

I see sections in the features doc for:

conjunction/disjunction/negation
is_invocable[_r]

I don't even see sections for the others.  Maybe I missed some things when enumerating the new C++17 features?

PK

Avi Drissman

unread,
Apr 27, 2022, 2:01:21 PMApr 27
to K. Moon, Lei Zhang, Dana Jansens, Jeremy Roman, cxx
I don't agree with that blanket statement; we have base:: versions of std:: stuff where the std:: version is insufficiently hardened (e.g. base::clamp vs std::clamp) where we ban the std:: version until we can get it equivalently hardened.

My question specifically about these items is if there is any specific reason that the std::replacement isn't a good replacement. Any change to the Features doc requires a discussion on cxx, even if it's a blanket OK covering a bunch of non-controversial items.

Let me just make a new thread.

K. Moon

unread,
Apr 27, 2022, 2:24:38 PMApr 27
to Avi Drissman, Lei Zhang, Dana Jansens, Jeremy Roman, cxx
I think that's a good point, but I would make a distinction between the feature and the implementation: We don't like the std implementation of some of the features, but we're still copying the basic design, with the original intent being that these are just backported std features that won't need duplicate implementations someday. If there's no intent to switch to the std version, I'd argue they should at least be spelled differently enough to highlight any differences in behavior.

Even in the case of something like absl::optional vs. std::optional, where there's a security objection to switching the libc++ version, keeping both is clearly suboptimal, and last I heard, there's active work going on to address that.

Anyway, for these features specifically, I agree that those should be resolved on the other thread. Hopefully there won't be any. :-)
Reply all
Reply to author
Forward
0 new messages