rjmccall wrote:
> > I really don't understand why `_BitInt` and `_Complex` are being brought up
> > here.
>
> I can explain my reasoning. `xxx int` can be read one of two ways: `xxx` is a
> type qualifier like `const` (e.g., `const int`) or is a type specifier like
> `_Complex` (e.g., `_Complex float`). If it's a qualifier, I expect lvalue to
> rvalue conversion to drop the extra qualifying information, but if it's a
> type specifier, I expect no change for the type on lvalue to rvalue
> conversion. To me, `__ob_trap` is far closer to a type specifier than it is a
> type qualifier; we don't want to drop the information on conversion.
>
> I think it would be confusing for template specializations to notice
> `__ob_trap` but overloading ignores it. e.g.,
>
> ```
> template <typename Ty>
> struct S {
> static constexpr int value = 0;
> };
>
> template <>
> struct S<int> {
> static constexpr int value = 1;
> };
>
> template <>
> struct S<__ob_trap int> { // Ok, not a redefinition
> static constexpr int value = 2;
> };
>
> void func(int) {}
> void func(__ob_trap int) {} // error: invalid redefinition
> ```
Oh, it's definitely a type specifier. However, because the intended design is
to drop this in while minimizing ABI incompatibility (to which I think should
be added: without directly impacting callers), I think there are strong design
arguments for applying certain qualifier-like behaviors to it, like ignoring it
at the top level of a parameter type when computing the signature of a function.
It is important to distinguish something requiring slightly more effort to
specify in a standard, which does not matter, and something being confusing for
users, which matters a lot. Your template vs. redeclaration example is exactly
what happens with qualifiers, and I do not think it has ever been a problem for
users. Actually allowing overloading based on a parameter being `__ob_trap int`
vs. `int`, when these types have exactly the same integer rank, would be
*extremely* confusing for users if they ever found themselves writing it. It is
the sort of language design mistake that leads to style guidelines that
actively resist what you were trying to accomplish in the language, like "never
declare a parameter `__ob_trap`".
https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
