I think there's an issue in your motivative example, thus actually the function parameter and object passed function (as its argument) are different entities, especially in the sense when some attributes attach to it.

Consider the following example:

```c++
consteval bool f([[maybe_unused]] int x) {
    static_assert(std::ranges::size(std::meta::attributes_of(^x)) != 0);
    return 0;
}

int main() {
    int x = 1;
    [[maybe_unused]] int y = 2;
    f(x); // should static_assert fail in this one?
    f(y);
    return f(1);
}
```

The above code:

1) Obviously breaking the ignorability of attributes, since whether static_assert fails depends on whether attributes exist; since we've already discussed I'll skip it here;
2) IMO we could not reach the "original" entity inside the function body, since currently `x` refers to a new entity declared in the function parameter scope, so it seems reasonably for me that static_assert shall not fail (i.e. std::ranges::size(std::meta::attributes_of(^x)) == 1 for f(x))
3) Further, we can argue that reflections of the following function's parameter (in the function parameter scope) also should not be preserve the attributes of the real arguments' either due to the consistency
   ```c++
  
    template <class F, class... Args>
    constexpr std::invoke_result_t<F, Args...> logInvoke(F&& f, Args&&... args);
   ```

Note: it seems to be a general issue in reflecting a function's parameter inside its parameter scope; I'm not sure whether that's been resolved or not.

 


On Sat, May 11, 2024 at 9:49 AM <sg7-request@lists.isocpp.org> wrote:
Send SG7 mailing list submissions to
        sg7@lists.isocpp.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/sg7
or, via email, send a message with subject or body 'help' to
        sg7-request@lists.isocpp.org

You can reach the person managing the list at
        sg7-owner@lists.isocpp.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SG7 digest..."


Today's Topics:

   1. Re: [SG7] Attributes introspection (Aurelien Cassagnes)


----------------------------------------------------------------------

Message: 1
Date: Sat, 11 May 2024 10:49:16 +0900
From: Aurelien Cassagnes <aurelien.cassagnes@gmail.com>
To: sg7@lists.isocpp.org
Subject: Re: [isocpp-sg7] [SG7] Attributes introspection
Message-ID:
        <CAJoReSdv0aheEqpWVh5DdovaZmPsoyO0xs-2GDTY0Ooyd=JQvg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks Cleiton for the feedback
Right now , I want to limit myself to standard attributes as I think this
makes it a somewhat more tractable problem space
Lmk if that makes sense.

I updated the draft at
https://github.com/zebullax/wg21/blob/main/generated/proposal.pdf
Cheers

Le sam. 27 avr. 2024 ? 13:20, Cleiton Santoia via SG7 <sg7@lists.isocpp.org>
a ?crit :

>       Sometime ago there were some proposals to allow User Defined
> Attributes as consteval or constexpr, but among other concerns, it
> conflicted with "attributes should not affect the program" and standard
> attributes are not "typed", and also not being part of the type of
> wherever they are attached. About that, we could change that to
>
> 1 - Apply "attributes should not affect the program" only on standard
> attributes the statement will become "*standard* attributes should not
> affect the program"
> 2 - Allow consteval UDA?s to be typed, and "affect" the program, I mean,
> by being constructed in compile time and anything derived from that,
> subjected to "normal" strong typed compile time behavior.
> 3 - *Not* be part of whatever type/template/declaration that it is being
> attached to.
>
>       In this spirit I had some thoughts about the subject taking this
> path, and giving my 2 cents ( mostly in template cases ) :
>
> 1 - It would be useful to reflect a single instance of attribute "
> my_attr1" for all instances of X and a different instance of the
> attribute " my_attr2" for each X instantiation.
>
> [[ my_attr1{} ]] template<typename T> [[  my_attr2<T>{} ]] struct X {};
> X<int>    x_int ;
> X<float>  x_float;
>
> so, if we ask for "attributes_of( type_of(^x_int) )", it should be
> expanded as
>
> constexpr auto temp1 =  my_attr1{};
> constexpr auto temp2 =  my_attr2<int>{};
> attributes_of( type_of(^x_int) ) == { ^temp1, ^temp2 };
>
> constexpr auto temp3 =  my_attr2<float>();
> attributes_of( type_of(^x_float) ) == { ^temp1, ^temp3 };
>
> instead of
>
> attributes_of( type_of(^x_int) )   == { my_attr1{} , my_attr2<int>{} };
> attributes_of( type_of(^x_float) ) == { my_attr1{} , my_attr2< float >{}
>  };
>
> so, subsequent calls to attributes_of( type_of(^x_int) ) would not
> construct other instances of  my_attr1 / my_attr2 , right ?
>
> 2 - What if my_attr3 does not depend on T ?. Well the same, one my_attr3
> to each instance
>
> [[  my_attr1{} ]] template<typename T> [[  my_attr3{
> constexpr_foo_counter() } ]] struct X {};
> X<int>  x_int  ;
> X<float>  x_float;
>
> constexpr auto temp1 = my_attr1{};
> constexpr auto temp2 = my_attr3{ constexpr_foo_counter()  };
> attributes_of( type_of(^x_int) ) == { ^temp1, ^temp2 };
>
> constexpr auto temp3 =  my_attr3{ constexpr_foo_counter()  };   //
> calling again possibly with different result
> attributes_of( type_of(^x_float) ) == { ^temp1, ^temp3 };
>
> 3 - Would it be possible to get the instance of my_attr1, without
> instantiation of X, also be possible to get the template name "my_attr2"
> without instantiating X, just reflecting the template ( not a particular
> instance )
>
> [[  my_attr1{} ]] template<typename T> [[  my_attr2<T>{} ]] struct X {};
>
> constexpr auto temp1 =  my_attr1{};
> attributes_of( ^X ) == { ^temp1, ^my_attr2 };
>
> 4 - Specializations should forget all previous attributes.
>
> template<> [[   my_attr4{} ]] struct X<void> {} x_void;
>
> constexpr auto temp1 =  my_attr4{};
> attributes_of( type_of(^x_void ) ) == { ^temp1  };
>
> Since one can get the "parent" attributes from de template declaration
>
> attributes_of( template_of( type_of(^x_void ) ) ) == attributes_of( ^X );
>
> 5 - All standard attributes must belong to a std:: namespace, avoiding
> conflict in future proposals.
>
>
> Thanks
>
> Em qua., 24 de abr. de 2024 ?s 08:30, Jean-Baptiste Vallon Hoarau via SG7 <
> sg7@lists.isocpp.org> escreveu:
>
>> What Barry was saying is that this cannot work : templates are
>> instantiated per type, and the attributes are not part of the type, so the
>> information is simply not passed down to the instantiation of the template,
>> reflection or not.
>>
>> Le mer. 24 avr. 2024 ? 13:26, Aurelien Cassagnes via SG7 <
>> sg7@lists.isocpp.org> a ?crit :
>>
>>> Barry I understand that right now there is no reasons for it to work,
>>> the purpose of this thread is to flesh out what the proposal look like.
>>> Gather interest and feedback not share an hypothetical  implementation
>>> because it doesnt exist yet.
>>>
>>> Besides seeing interest, the feedback i?m interested is what sections
>>> need to be discussed in more detail in the draft for it to become more
>>> meaningful
>>> thanks.
>>>
>>> Sent from Gmail Mobile
>>>
>>>
>>> On Sun, Apr 21, 2024 at 1:47 Barry Revzin <barry.revzin@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Apr 19, 2024, 9:53?PM Aurelien Cassagnes via SG7 <
>>>> sg7@lists.isocpp.org> wrote:
>>>>
>>>>> Fleshed out the proposal draft and it's available for feedback at
>>>>> https://github.com/zebullax/wg21/blob/main/generated/proposal.pdf
>>>>>
>>>>
>>>> How do you expect this to work exactly?
>>>>
>>>> The type of foo is bool(int),  it's not [[nodiscard]] bool(int).
>>>> Regardless of the question of reflecting on attributes... logInvoke(foo, 0)
>>>> is going to call logInvoke<bool(int), int>. There aren't any attributes
>>>> left to reflect on anymore.
>>>>
>>>> Barry
>>>>
>>>>> --
>>> SG7 mailing list
>>> SG7@lists.isocpp.org
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>>
>> --
>> SG7 mailing list
>> SG7@lists.isocpp.org
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>
> --
> SG7 mailing list
> SG7@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Subject: Digest Footer

SG7 mailing list
SG7@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg7


------------------------------

End of SG7 Digest, Vol 33, Issue 1
**********************************