[llvm-bugs] [Bug 46691] New: Enhancement: allow requires-clause checking of statement expression substitution success or failure
via llvm-bugs
llvm-bugs at lists.llvm.org
Sun Jul 12 08:39:16 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=46691
Bug ID: 46691
Summary: Enhancement: allow requires-clause checking of
statement expression substitution success or failure
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++2a
Assignee: unassignedclangbugs at nondot.org
Reporter: wjwray at gmail.com
CC: blitzrakete at gmail.com, erik.pilkington at gmail.com,
llvm-bugs at lists.llvm.org, richard-llvm at metafoo.co.uk
SFINAE on structured bindings would provide a way to count the number
of bindings in a type at compile time (pending static reflection).
Knowing the count then allows to decompose any structured-bindable type.
SFINAE can only test expressions.
To check a structured binding statement it has to be wrapped as a
statement expression (non standard gnu extension in C++, from C).
This is a request to consider allowing checking of statement expressions
within requires clauses (probably limited to local function scope only)
as an enhancement.
Checking in requires clauses seems like the most direct approach:
https://godbolt.org/z/sM51f5
template <typename T> constexpr int arity()
{
if constexpr (requires (T& a) { ({auto [x] = a;}); }) return 1;
else if constexpr (requires (T& a) { ({auto [x,y] = a;}); }) return 2;
// ... etc ... 3,4,5 ... N
else
return 0;
};
Clang accepts the template but fails all requires clauses to always return 0.
Clang since v5 already apparently allows statement-expression SFINAE
in trailing return type https://godbolt.org/z/YYPbvq:
template <typename T> auto arity_impl() {
return overloads{
[](auto&& u,int) -> decltype(({auto&& [x] = u; &"";})) {return {};},
[](auto&& u,int) -> decltype(({auto&& [x,y] = u; &"2";})) {return {};},
...
[](auto&& u,unsigned) -> void {}
}(declval<T>(),int{});
}
(the check can be done in default argument to Clang 10, broken on 11 trunk)
So, there's a solution to this in Clang since v5, but on shakey ground.
I know of no solution in GCC so I've made a similar enhancement request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96170
It seems that Clang is close to this already, so hopefully a small change.
Thanks for your considerations.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200712/90ea5ce4/attachment.html>
More information about the llvm-bugs
mailing list