Support conversion between types
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- rust
- Domain
- backend-api-design
Research direction
Start by reviewing the existing implicit deserialization behavior and how nodes route errors to the on_implicit_error target. Define the intended behavior for Into, opt-in TryInto, and lossless primitive conversions, including where conversion settings belong and how successful and failed conversions should be recognized as done.
Written by the indexing model from the issue text.
Description
Rust has excellent support for converting between data types with the Into, From, TryFrom, and TryInto traits. We could leverage these traits to allow users to register conversions between message types. We could support implicit conversion for any output type that supports Into<T> for its target input.
We could also support implicit conversion when TryInto is available, but this might be an opt-in setting that the user toggles at the diagram level or inside the specific node where the implicit conversion should be allowed. Just like implicit deserialization, an implicit TryInto would direct errors towards the on_implicit_error target.
We should also automatically support implicit conversions from smaller primitives to larger primitives where there is no risk of overflow or loss of precision, e.g. i8 -> i16 -> i32 -> i64, or less obviously u8 -> i16, u16 -> i32.
- Dominant language
- Rust
- Stars
- 75
- Forks
- 18
- Avg merge
- 12d 12h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-rmf/crossflow
-
Diagram editor fails to build on Windows: build.rs can't find pnpm (pnpm.cmd)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
All issues in open-rmf/crossflow
Similar issues
-
comp-formats
Difficulty 2/5 Half a day Newbie friendliness 64/100
ClickHouse/ClickHouse#131694 ·
Maintainers usually reply within 1 day
-
cli: `execCargoMetadata` decodes stdout per chunk, corrupting non-ASCII paths across pipe boundariesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Copperpour/Copperpour#500 ·
Maintainers usually reply within 1 day
-
state:triage-needed
Difficulty 1/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day