================
@@ -1938,7 +1902,7 @@ def EnableIf : InheritableAttr {
// Does not have a [[]] spelling because this attribute requires the ability
// to parse function arguments but the attribute is not written in the type
// position.
- let Spellings = [GNU<"enable_if">];
+ let Spellings = [Clang<"enable_if">];
----------------
AaronBallman wrote:
> Hmm I see. Before I give up, could I get your thoughts on [my last
> question](https://github.com/llvm/llvm-project/pull/225900#issuecomment-5804354535)?
> Like what concrete problem could arise if we allowed this to work in the
> type position, but operate on the declaration? Could the standard conceivably
> mandate that it actually modify the type somehow? That seems pretty much
> impossible to me for something whose meaning the standard doesn't dictate, so
> what else could go wrong?
Having a clear appertainment model is why we have `[[]]` instead of
`__attribute__` in the standard. It's a basic underlying principle for the
feature that lexical position of the attribute list determines exactly what the
attribute is applied to. So could we ignore the rules and allow a type
attribute to just have declaration properties? Sure. But we're not going to.
The kinds of questions that come up around type attributes are things like "can
you specialize a template on this?" or "can you overload a function based on
this?", etc. Vendor attributes have latitude to answer these questions however
we want, but generally speaking, if it impacts the type it will impact things
like conversions. e.g.,
```
void func() [[vendor::attr]]; // Type attribute
void other_func();
void (*fp)() = func; // Is this a type conversion error?
void (*other_fp)() [[vendor::attr]] = func; // Is this a type conversion error?
int main() {
fp(); // If there was no conversion error, do the attribute semantics still
happen in this case?
}
```
https://github.com/llvm/llvm-project/pull/225900
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
