On 1/23/25 5:11 PM, Nathaniel Shead wrote:
On Thu, Jan 23, 2025 at 04:47:32PM -0500, Jason Merrill wrote:
On 1/6/25 7:24 AM, Nathaniel Shead wrote:
Happy to defer this till GCC16 if preferred.
-- >8 --
This fills in a hole left in r15-6378-g9016c5ac94c557 with regards to
detection of TU-local lambdas. Now that LAMBDA_EXPR_EXTRA_SCOPE is
properly set for most lambdas we can use it to detect lambdas that are
TU-local.
Lambdas in concept definitions I believe should not be considered
TU-local, since they are always unevaluated and should never be emitted.
It seems to me that they are also TU-local under
https://eel.is/c++draft/basic#link-15.2 . It might be feasible to change
that, but that is the status quo.
Right, sorry I wasn't clear; I agree that this is the status quo, I just
think that we should accept them; otherwise, currently we would reject
exporting any concept with a lambda contained within it, which seems
needless hostile (and causes a number of tests to fail).
In particular, lambdas within concepts are actually made use of within
the standard library, e.g. optional:1683, so we would either need to
continue to allow this to work somehow (either via mangling scope or a
new flag on the lambda, because there's no other way I was able to find
of determining this), or rewrite the concept to not use a lambda.
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 3746. optional's spaceship with U with a type derived from optional
// causes infinite constraint meta-recursion
template<typename _Tp>
concept __is_derived_from_optional = requires (const _Tp& __t) {
[]<typename _Up>(const optional<_Up>&){ }(__t);
};
Agreed, I've sent mail to CWG proposing adding concept-definition to the
list in basic.link/15.2. Thanks for the example.
Jason
