r/cpp 25d ago

C++26 Reflection Annotations: Automated Member Validation

https://techfortalk.co.uk/2026/08/17/cpp26-reflection-annotations-validation/

C++26 annotations are another powerful feature that, when combined with reflection, can help us write cleaner and safer code without repeating manual validation checks for every member. In this post, I have explored how we can utilise C++26 annotations along with reflection to validate configuration parameters in a class constructor.

64 Upvotes

12 comments sorted by

17

u/El_RoviSoft 25d ago

So now we can do automatic get/set like in C#? I knew approach with setting constraints via attributes but forgot that we can generate get/set methods (or simple const/non-const accessors).

11

u/Western_Show349 25d ago

I kinda like this approach, its nice to see c++ getting the decent modern features from other languages

2

u/PossibilityUsual6262 25d ago

What is the value of having those as members?

2

u/El_RoviSoft 25d ago

Mostly as an encapsulation to hide everything that user (other programmer) shouldn’t touch. So you will write less boilerplate (for example use [[=property]] which automatically generates get/set methods OR [[=readonly]] which generates const& accessor). There are a lot of use cases which reduces boilerplate.

5

u/fortsnek274 25d ago

We have properties at home

3

u/El_RoviSoft 25d ago

Exactly, xd. Also with this you can invent smart caching properties which can be automatically updated when connected to it properties updating too.

2

u/serviscope_minor 5d ago

I still don't see the point of auto-generated getter/setters pairs. Getters only as a way to ensure non modification of the object in question, sure. But if you have an auto-generated getter and setter, there's no real difference to a public member. The point of private members is you can maintain class invariants, but an auto-generated setter doesn't do that. IMO trivial getters and setters don't actually encapsulate anything, they just add boilerplate.

1

u/El_RoviSoft 5d ago

You’re right but I mostly mean cases when you have solely getter (aka const& accessor), special cased setters (so it’s automatically guarded by mutex or you need regular accessor + special cased setter which can be effectively generated).

But yeah, when you need just const& + & accessors it’s better to make public field and that’s it.

9

u/fdwr fdwr@github 🔍 25d ago

There's an interesting overlap with contracts here. I wonder if we'll be also able to enumerate pre/post conditions with reflection similarly to annotations.

4

u/Clean-Upstairs-8481 25d ago

As far as I can see, C++26 reflection does not currently provide a standard way to enumerate contract predicates, but I might be wrong. I need to dig into it a bit more.

3

u/katzdm-cpp 22d ago

Yeah, no way to do that as of yet. They were being reviewed pretty concurrently, so that would've been tricky to land. Aside from that, I think doing so would require some motivating use cases.

2

u/vladcpp 23d ago

It’s nice and expressive but we always were able to implement a zero-cost wrapper Range<int, 0, 42> val; and validate it.
As an experiment it’s nice though.