Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A char is clearly defined in IDL, and the conversion from IDL->python, IDL->C++, IDL->C for a char all seems to exist, yet currently char is converted to uint8 in rosidl_adapter. Is there a reason for this conversion?
Currently:
char
->uint8
then,uint8
->uint8_t
uint8
->int
But to me what makes sense, would be:
char
->char
then,char
->char
(char8_t
in c++20, butuint8_t
if we want to really specify 8 bit usage)char
->str
with length 1The design docs will have to be updated if these change.
UPDATE:
I just realised that
char
has been deprecated since ROS 1, and the conversion is somewhat justified - quoting ROS 1 msg:and in ROS2 design, it mentions:
Is this deprecation ongoing, and would it be possible to add a deprecation notice somewhere during compilation?
Separate point -
byte
doesn't seem like an alias forint8
as explained in the quotes above, it maps tounsigned char
for C++...