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_at_[hidden]> wrote:

> Send SG7 mailing list submissions to
> sg7_at_[hidden]
>
> 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_at_[hidden]
>
> You can reach the person managing the list at
> sg7-owner_at_[hidden]
>
> 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_at_[hidden]>
> To: sg7_at_[hidden]
> Subject: Re: [isocpp-sg7] [SG7] Attributes introspection
> Message-ID:
> <CAJoReSdv0aheEqpWVh5DdovaZmPsoyO0xs-2GDTY0Ooyd=
> JQvg_at_[hidden]>
> 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_at_[hidden]>
> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]>
> >>> wrote:
> >>>
> >>>>
> >>>>
> >>>> On Fri, Apr 19, 2024, 9:53?PM Aurelien Cassagnes via SG7 <
> >>>> sg7_at_[hidden]> 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_at_[hidden]
> >>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> >>>
> >> --
> >> SG7 mailing list
> >> SG7_at_[hidden]
> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> >>
> > --
> > SG7 mailing list
> > SG7_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> >
> -------------- next part --------------
> HTML attachment scrubbed and removed
>
> ------------------------------
>
> Subject: Digest Footer
>
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
>
> ------------------------------
>
> End of SG7 Digest, Vol 33, Issue 1
> **********************************
>