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

[Lei Zhang]

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]

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]

Agree, please go for it.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACuR13ciZcyaQ0QYa425ZsQiSC4jwhBixu%3DTH_yt%3Dqfh0pHtyw%40mail.gmail.com.

[Lei Zhang]

Filed crbug.com/1320019 for this.

[Avi Drissman]

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@?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACSHbcR5Hd9XLsvfxnaFs44LBaE__WEpraMhCwV2prhr1VwyGw%40mail.gmail.com.

[K. Moon]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CACWgwAb-phLzKid1Xe_%2BaGkam8xRm-tCqguTjsX0ond8ZXxNTQ%40mail.gmail.com.

[Peter Kasting]

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]

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]

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. :-)