Skip to content

Add a deprecation warning to tl_expected#18

Merged
christophfroehlich merged 2 commits intohumblefrom
add/deprecationwarning
Mar 25, 2026
Merged

Add a deprecation warning to tl_expected#18
christophfroehlich merged 2 commits intohumblefrom
add/deprecationwarning

Conversation

@christophfroehlich
Copy link
Collaborator

No description provided.

@christophfroehlich
Copy link
Collaborator Author

@otamachan do you support this?

@otamachan
Copy link
Contributor

I'm in favor of adding a deprecation warning, but one concern: on Jazzy and Humble (both use the Humble branch of generate_parameter_library), this warning would be triggered by generate_parameter_library's headers, so users would see warnings they can't suppress from their side — until generate_parameter_library itself migrates away from tl_expected/expected.hpp. We use Jazzy, so this would affect us.

Would it make sense to add an option in generate_parameter_library's Humble branch to optionally use libexpected-dev instead? The default would keep the current behavior for backward compatibility, but
users who have libexpected-dev available could opt in to suppress the warning.

@christophfroehlich
Copy link
Collaborator Author

This is a valid concern, maybe we could even backport PickNikRobotics/generate_parameter_library#322 as it is? It will annoy users with deprecation warnings, but it could avoid breaking changes for lyrical release.
I'm also open to release jazzy+kilted from a different branch, and leave humble as it is. additional maintenance overhead is minimal I'd say.

@otamachan
Copy link
Contributor

Ah, I found that the Jazzy release of RSL already uses <tl/expected.hpp> from libexpected-dev (https://github.com/ros2-gbp/rsl-release/blob/debian/jazzy/noble/rsl/include/rsl/parameter_validators.hpp#L10). RSL releases from a single branch, all distros use libexpected-dev. And since librsl.so exports to_parameter_result_msg(tl::expected<void, std::string> const&), generate_parameter_library should also use libexpected-dev to ensure ABI consistency. So backporting PickNikRobotics/generate_parameter_library#322 actually makes sense.

My only concern is that if there are existing binaries built against tl_expected/expected.hpp (vendored 1.2.0), they could have ABI mismatches with libexpected-dev.

@christophfroehlich
Copy link
Collaborator Author

Oh you are right. We potentially already broke ABI of packages of parameter_traits on humble:
1.3.0 of rsl is already released and synced: http://packages.ros.org/ros2/ubuntu/dists/jammy/main/binary-amd64/Packages

Package: ros-humble-rsl
Version: 1.3.0-1jammy.20260313.125303

This is maybe no real problem as these all are header-only libraries? and as they are API compatible, any rebuild should work?

Copy link
Contributor

@otamachan otamachan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Since librsl.so with libexpected-dev is already released and synced on Humble, I think backporting PickNikRobotics/generate_parameter_library#322 to the Humble branch makes sense too.

@christophfroehlich christophfroehlich merged commit 8d0d91d into humble Mar 25, 2026
14 checks passed
@christophfroehlich christophfroehlich deleted the add/deprecationwarning branch March 25, 2026 19:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants