Hey ykiko,

I think the current plan is to build something like this on top of P2996, but likely not for C++26. Some papers have been proposed in the past: Bret Brown wrote P2565 ("Supporting User-Defined Attributes") in 2022, and Corentin Jabot wrote P1887 ("Reflection on Attributes") in 2020. I think some folks have been waiting for P2996 to advance further through the Committee before investing more time in the idea (maybe now is a good time to revisit?)

An SG7 thread from October suggested that this be a separate feature from attributes (i.e., "annotations") that attaches an arbitrary (and non-ignorable) constexpr struct to a declaration.

Best,
---Dan


From: sg7_at_lists.isocpp.org At: 05/12/24 15:01:10 UTC-4:00To: sg7_at_[hidden]
Cc: saksham0808_at_[hidden]
Subject: Re: [isocpp-sg7] Customized metadata for reflection

Hi,

My two cents on this topic.

I believe user defined attributes is not a bad idea per-se. Serialization / deserialization is simply one of the use-cases. There's others, like command-line parsing (annotating the cmdline flag corresponding to the field name), python bindings (picking whether return type of a function is returned to python as a reference or as a value), I think the list goes on.

My favorite syntax for this is Golang's annotation (source of snippet : https://www.makeuseof.com/reflection-in-go/). Of course we won't want this in C++ but just as an example.
```
type User struct {
   Name string `json:"name" required:"true"`
}
user := User{"John"}
field, ok := reflect.TypeOf(user).Elem().FieldByName("Name")
fmt.Println(field.Tag, field.Tag.Get("required"))
```

Anyhow, there's various reasons I think as to why this is not a make-or-break thing right now. Some of those are mentioned here in P2911 under the section "Customization". The gist of my thoughts:

1. Customization at the point of definition is not the only way to do things. As shown in P2996 Command Line Arguments II section, if we're willing to do a little bit more work, we can get away with a decent interface. Especially if there's no existing point of definition. If there is, then the approach mentioned in P2911 earlier works similarly. But without the define_class from in the P2996 link.
2. Customization at the point of definition is also not applicable in situations where you don't have control over the source code.

Hopefully, if someday user-defined attributes do land, they would be made to work with P2996 and we'll have the ideal choice (customization at the point of definition, or at the point of use). That would certainly make serialization libraries better UX wise.

Regards,
Saksham


On Sun, May 12, 2024 at 11:24 AM ykiko via SG7 <sg7_at_[hidden]> wrote:

I think P2996 lacks an important feature, that is, customized metadata for reflection. As we all know, we can serialize and deserialize struct automatically through static reflection, but sometimes, for some fields (maybe private), we want to skip it. It is a common demand, But unfortunately, there is no way to allow users to attach metadata to fields in P2996 currently.

In other languages, customized metadata is widely used. For example, we can mark a field [JsonIgnore] in C# and #[serde(skip_deserializing)] in Rust to skip fields for serialization. Besides, although C++ does not have reflection now, some frameworks implement reflection on their own through code generation. They all support customized metadata. For example, UPROPERTY in UE and Q_PROPERTY in QT. Clang and GCC also support an attribute to expose metadata in AST, which is [[clang::annotate("")]]; some code generation tools use it to customize metadata.

So, in my opinion, we cannot write a serialization library based on P2996 that is as convenient as those in other languages without a way to allow users to customize metadata. I suggest adding a new attribute [[annotate(constant-expression, ...)]] to allow users to attach metadata to some entries. And, we can use reflection to get the annotations of entries.

This topic may be related to the proposal Attributes Introspection. And the idea is at an early stage, any suggestion is welcome.

ykiko.
 --
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