Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanups after CWG2672 #6718

Open
zygoloid opened this issue Dec 4, 2023 · 1 comment
Open

Cleanups after CWG2672 #6718

zygoloid opened this issue Dec 4, 2023 · 1 comment

Comments

@zygoloid
Copy link
Member

zygoloid commented Dec 4, 2023

A couple of editorial cleanups would seem nice post-CWG2672:

  1. In the writeup of CWG2672, I suggested: "[...] move the rule somewhere more general", which has not happened. The general rule that substitution into a lambda-expression considers the body to not be in the immediate context, which applies to all substitutions, is still in [temp.deduct.general], the section on template argument deduction.

  2. The example in [temp.deduct.general]/9, immediately after the normative wording changed by that issue, doesn't match the rule. Prior to CWG2672, the rule was that all substitution into a lambda-expression during template argument deduction was not in the immediate context, and afterwards, the rule is that only substitution into the body is in the immediate context (but it doesn't matter if we're doing template argument deduction or something else). In particular, the h example is now valid:

template <class T>
  auto h(T) -> decltype([x = T::invalid]() { });
void h(...);
h(0);               // error: invalid expression not part of the immediate context

... should presumably say something like OK; invalid expression is in the immediate context.

@frederick-vs-ja
Copy link
Contributor

frederick-vs-ja commented Feb 16, 2024

This case in the example looks a bit weird:

template <class T, std::size_t = sizeof([]() { T::invalid; })>
  void g(T);
void g(...);
g(0);               // error: invalid expression not part of the immediate context

The example suggests that the body of lambda expression is instantiated, which results in hard error (implementations agree).
However, given the lambda expression is not called and return type deduction shouldn't happen, is there anything requiring instantiation of the lambda body?

It seems that the lambda body needs to be substituted into but the member operator() (or the similar function pointed to by the result of conversion function) isn't instantiated. This is perhaps fine but looks a bit inconsistent to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants