cor3ntin wrote:
Copy of a mail I sent to CWG
---
This issue comes from an old LLVM issue reported by Richard, which I thought I
could fix in a few minutes.
I was wrong.
Consider the following:
```cpp
(S())[]->A<int>; // #1
(S())[]->A<int> {return {};}; //#2
```
**<https://gcc.godbolt.org/z/a8j1ac9fj>**\
This is yet another flavor of ambiguity caused by declarator syntax, which I
don't think we have wording to resolve.
#1 is a parenthesized constructor call, followed by\
calls to some `operator[]`, `operator->`
#2 is an (invalid) C-cast of a lambda expression.
You would think that it is easy to tell these things apart because of the
opening brace in #2.
However, this forces us to decide if the entity after the arrow is a type or an
expression.\
We also can't look into whatever the declaration context of the\
type of result of a potential operator-> call that we have not resolved yet.
There is no clever way to balance the tokens as could be a valid\
binary operator. eg
`(S())[]->A < some expression;`
Trying to determine if the thing after -> is a type may force us to do template
instantiations.\
So I think we need a rule in the spirit of
<https://eel.is/c++draft/dcl.ambig.res#2>to deal with that case
We should resolve that in favor of the thing after the arrow\
being a type, and forcing the expression to be a lambda, even though it might
not be a valid one.
I think other cases can be resolved syntactically,\
including `(S())[] < expr; // We can tell expr is not a template parameter`
No compiler gets that right currently, both GCC (afaict) and Clang assume [
after as cast is always a lambda
https://github.com/llvm/llvm-project/pull/140053
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
