This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Avoid `result_type` and `unary/binary_function` in <valarray>
ClosedPublic

Authored by Quuxplusone on May 29 2021, 2:12 PM.

Details

Summary

Give each of the relevant functional operators a __result_type instead, so that we can keep using those typedefs in <valarray> even when the public binder typedefs are removed in C++20.

This is a bit of a hacky lazy way to eliminate valarray's dependency on {unary,binary}_function, but it kinda seems like all of valarray is a hack and so maybe this fits right in? ;)
I would be willing to spend some time trying to recast all this metaprogramming in terms of decltype, but the first thing I tried didn't immediately work, so I went with the safe route.

The main point of this patch is to clear the way for _LIBCPP_ENABLE_CXX20_REMOVED_BINDER_TYPEDEFS (and incidentally _LIBCPP_ABI_NO_BINDER_BASES), which I have already got in a local patch on top of this one.

Diff Detail

Event Timeline

Quuxplusone requested review of this revision.May 29 2021, 2:12 PM
Quuxplusone created this revision.
Herald added 1 blocking reviewer(s): Restricted Project. · View Herald TranscriptMay 29 2021, 2:12 PM
libcxx/include/functional
1005–1007

Btw, we could eliminate 9 lines of custom __bit_not<T> code from <valarray> if we made std::bit_not<T> here available in C++03 mode as an extension. Thoughts?

libcxx/include/valarray
446

Btw, I was surprised to find value_type here instead of result_type. But changing it (or even trying to produce a test case where the difference was observable) seemed like a rabbit hole, so I avoided it.

libcxx/include/valarray
446

Today I think I've convinced myself that it doesn't matter: _Op::__result_type is always either _Tp or bool, and we only ever use _BinaryOp in type-expressions like __val_expr<_BinaryOp<...>>, and __val_expr::operator[](size_t) does correctly return __result_type; so at worst we're taking a bool, accidentally casting it up to _Tp here in _BinaryOp::operator[], and then casting it back down to bool in __val_expr::operator[]. I don't think this is ever observable.

So I could "fix" this, or leave it as-is; either way it wouldn't be observable.

ldionne accepted this revision.May 31 2021, 7:51 AM
ldionne added inline comments.
libcxx/include/functional
1005–1007

I'd rather not do that. We'll waste more than that in complexity for testing the extension.

This revision is now accepted and ready to land.May 31 2021, 7:51 AM
This revision was landed with ongoing or failed builds.May 31 2021, 8:29 AM
This revision was automatically updated to reflect the committed changes.