[meta.reflection.queries] [dcl.fct] Disagreement about whether `int()const` is const qualified

[Halalaluyafail3]

In [dcl.fct] there exists the following note:

A function type that has a cv-qualifier-seq is not a cv-qualified type; there are no cv-qualified function types.

However, [meta.reflection.queries] has the following wording for std::meta::is_const and std::meta::is_volatile:

Returns: true if T represents a const or volatile type, respectively, or a const- or volatile-qualified function type, respectively. Otherwise, false.

The former states that there are no cv-qualified function types, while the latter is directly implying the possibility of cv-qualified function types (otherwise the second half of the first sentence would be redundant). It is quite clear what the latter is trying to state, that is_const(^^int()const) should be true. But if int()const really is a const qualified type, then std::is_const_v<int()const> should be true too which is obviously not intended.

Also, the subsequent definition of std::meta::is_lvalue_reference_qualified and std::meta::is_rvalue_reference_qualified contains:

Returns: true if T represents an lvalue- or rvalue-qualified function type, respectively. Otherwise, false.

The intent here is clear too but "lvalue-qualified" and "rvalue-qualified" do not get used anywhere else.

[frederick-vs-ja]

Maybe we should say

[...] or a function type having const or volatile in its trailing cv-qualifier-seq [...]

and

[...] a function type whose ref-qualifier is & or && [...]

instead.

[term-est]

    struct S
    {
        void func() const {}
        void func2(this const S&) {}
    };

    static_assert(is_const(^^S::func)); // 1
    static_assert(is_const(^^S::func2)); // 2

I think we want both assertions to pass. Albeit both GCC and clang 2996 fails the 2nd assert.

[...] or a function type having const or volatile in its trailing cv-qualifier-seq [...]

Assuming we want static_assert(is_const(^^S::func2)) to pass, the wording needs to include explicit object parameters as well.
But, that seems to be a rabbit hole of its own

Consider

    struct S
    {
        void func(this const int&) {}
        operator int() { return {}; }
    };

    static_assert(is_const(^^S::func)); // ?

So, we perhaps want something along the lines of:

[...] or r represents a non-static member function of a class C, and either

• its function type has const or volatile, respectively, in its cv-qualifier-seq, or
• it is an explicit object member function whose explicit object parameter:
  • has a const- or volatile-qualified type, respectively, after removing any reference; and
  • has type C after removing cv-qualifiers and references.

And similarly for is_lvalue_reference_qualified and is_rvalue_reference_qualified, checking only the reference type of the explicit object parameter is insufficient:

Consider

struct S
{
    void func(this int&&) {}
    operator int&&(this auto&&)
    {
        static int i{};
        return std::move(i);
    }
};

const S s{};
s.func();

static_assert(is_rvalue_reference_qualified(^^S::func)); // should return false

Perhaps,

Returns true if T represents:

• a function type whose ref-qualifier is & or &&, respectively; or
• r represents an explicit object member function of a class C whose explicit object parameter:
  • has lvalue reference type or rvalue reference type, respectively; and
  • has type C after removing cv-qualifiers and references.

Otherwise, false.

That all assumes we want to support explicit object parameters, though. I am under the impression that, users will expect explicit object parameters to be analogous to their cv-qualifier-sequence counterparts, so there is value in supporting this.

The scope of this goes beyond editorial though. LMK if we want an LWG issue on this

[Halalaluyafail3]

    struct S
    {
        void func() const {}
        void func2(this const S&) {}
    };

    static_assert(is_const(^^S::func)); // 1
    static_assert(is_const(^^S::func2)); // 2

I think we want both assertions to pass. Albeit both GCC and clang 2996 fails the 2nd assert.

I do not see why that should be the case. What you are describing should probably be its own trait if it is useful, though I think that the function type uses of is_const and is_volatile should have been split into separate functions to avoid confusion.

[frederick-vs-ja]

struct S
    {
        void func() const {}
        void func2(this const S&) {}
    };

    static_assert(is_const(^^S::func)); // 1
    static_assert(is_const(^^S::func2)); // 2

I think we want both assertions to pass. Albeit both GCC and clang 2996 fails the 2nd assert.

Given the type of S::func2 is void(const S&), is_const should handle it in the same way as non-member functions.

It's a bit complicated to distinguish explicit member functions from non-member functions in is_const etc.. This kind of change is certainly non-editorial and might even need LEWG to approve. I personally don't want it.