Stay up-to-date with everything C++!
Content directly fetched from the subreddit just for you.
Join our group for discussions : @programminginc
Powered by : @r_channels
Post #23961
16
not be queried: https://godbolt.org/z/r19185rqr**
Which means one can not put a hypothetical `noconvert(bool)` annotation on a parameter for which one would not like implicit conversions on the python side. (Or rather, one can not find the annotation with `annotations_of()`).
The alternative is to annotate the function with an array-like list of indices for which implicit conversions are undesirable. This is a pretty error prone option that is brittle in the face of refactoring and signature changes.
I know that annotations and function parameter reflections have moved through WG21 in parallel and hence the features don't work with one another, but annotating parameters would be quite useful.
**Parameter reflections can't give us default values of the reflected parameter**
This is a can of worms. Default values need not be constant expressions, need not be consistent between declarations, and [can even "stack"](https://godbolt.org/z/Ycf9hdxxr).
However, the lack of ability to get some sort of reflection on the default value of a parameter paints us in a corner where we have to bind the same function multiple times, always wrapped in a lambda, to emulate calling a function with different number of arguments.
Here's an example: https://godbolt.org/z/Yx17T8fYh
Binding the same function multiple times creates a runtime overload set, for which pybind11 performs runtime overload resolution in a case where manual binding completely avoids the runtime overloading mechanisms.
Yes, my example with `int y = 3` parameter is very simple and avoids all the hard questions.
From where I stand, it would be enough to be able to splice a token sequence matching the default argument value.
There is a case that I don't know how I'd handle: https://godbolt.org/z/Ys1nEsY6r
But this kind of inaccessible default parameters could never be defaulted when it comes to pybind11.
## Conclusion
C++26 Reflections are amazing and the upcoming token sequences would make it even more so.
Still, there is a thing or two that I have not noticed is in planning for C++29. Specifically:
- Function parameter annotations and reflection of default values would be extremely useful. If there's one thing I'd like to get in the future, it's this one.
- Range splicers, of the form `[:...range:]` would clean up some things too.
- Template annotations as a distant 3rd for automatically generating bindings for template instantiations.
So that I don't end on a note that might look entitled, once again, a sincere thank you to everyone involved in C++ Reflections.
EDIT1: Fixed sloppy wording when it comes to parameter annotations.
https://redd.it/1nw39g4
@r_cpp
Which means one can not put a hypothetical `noconvert(bool)` annotation on a parameter for which one would not like implicit conversions on the python side. (Or rather, one can not find the annotation with `annotations_of()`).
The alternative is to annotate the function with an array-like list of indices for which implicit conversions are undesirable. This is a pretty error prone option that is brittle in the face of refactoring and signature changes.
I know that annotations and function parameter reflections have moved through WG21 in parallel and hence the features don't work with one another, but annotating parameters would be quite useful.
**Parameter reflections can't give us default values of the reflected parameter**
This is a can of worms. Default values need not be constant expressions, need not be consistent between declarations, and [can even "stack"](https://godbolt.org/z/Ycf9hdxxr).
However, the lack of ability to get some sort of reflection on the default value of a parameter paints us in a corner where we have to bind the same function multiple times, always wrapped in a lambda, to emulate calling a function with different number of arguments.
Here's an example: https://godbolt.org/z/Yx17T8fYh
Binding the same function multiple times creates a runtime overload set, for which pybind11 performs runtime overload resolution in a case where manual binding completely avoids the runtime overloading mechanisms.
Yes, my example with `int y = 3` parameter is very simple and avoids all the hard questions.
From where I stand, it would be enough to be able to splice a token sequence matching the default argument value.
There is a case that I don't know how I'd handle: https://godbolt.org/z/Ys1nEsY6r
But this kind of inaccessible default parameters could never be defaulted when it comes to pybind11.
## Conclusion
C++26 Reflections are amazing and the upcoming token sequences would make it even more so.
Still, there is a thing or two that I have not noticed is in planning for C++29. Specifically:
- Function parameter annotations and reflection of default values would be extremely useful. If there's one thing I'd like to get in the future, it's this one.
- Range splicers, of the form `[:...range:]` would clean up some things too.
- Template annotations as a distant 3rd for automatically generating bindings for template instantiations.
So that I don't end on a note that might look entitled, once again, a sincere thank you to everyone involved in C++ Reflections.
EDIT1: Fixed sloppy wording when it comes to parameter annotations.
https://redd.it/1nw39g4
@r_cpp
