https://github.com/AaronBallman commented:
Thank you for working on this! I think there's something here worth
considering: how an implementation handles use of underspecified declarations
is left implementation-defined. I think we want to diagnose many of the
situations it covers, but I think we already have most of those diagnostics
covered.
The one thing that's not covered is declaring or defining new identifiers as
part of an underspecified declaration. However, we might want to accept that as
an extension rather than follow GCC's footsteps. C users are used to the fact
that you can define a type basically anywhere you can spell a type name. Is it
confusing? Absolutely. But I think it's just as confusing to allow users to
define a type in *some* places but not others, along fairly arbitrary lines. In
other words, it's weird to me that we would allow:
```
void func() {
int x = (struct Foo { int x; }){ 0 }.x;
}
```
but would reject:
```
void func() {
constexpr int x = (struct Foo { int x; }){ 0 }.x;
}
```
So support for this paper might entail adding documentation for what our
implementation-defined behavior is when we accept code + test coverage, rather
than rejecting code because GCC rejects it.
CC @zygoloid @jyknight @jrtc27 @nickdesaulniers for some more opinions on this.
https://github.com/llvm/llvm-project/pull/79845
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
