Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ron: Support for non-String map keys #432

Open
MhhhxX opened this issue Apr 12, 2023 · 2 comments
Open

Ron: Support for non-String map keys #432

MhhhxX opened this issue Apr 12, 2023 · 2 comments

Comments

@MhhhxX
Copy link

MhhhxX commented Apr 12, 2023

I have found that deserialising maps with this crate works differently from the deserialisation function of the ron crate.

I have taken the map from the example ron file available on the ron github page. With this I have extended the test for the ron format in my own fork of this repo.

And unfortunately the test fails with the following error:

called `Result::unwrap()` on an `Err` value: Expected a string but found the signed integer `1` instead in tests/Settings.ron
thread 'test_file' panicked at 'called `Result::unwrap()` on an `Err` value: Expected a string but found the signed integer `1` instead in tests/Settings.ron', tests/file_ron.rs:38:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/result.rs:1790:5
   3: core::result::Result<T,E>::unwrap
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/result.rs:1112:23
   4: file_ron::make
             at ./tests/file_ron.rs:35:5
   5: file_ron::test_file
             at ./tests/file_ron.rs:43:13
   6: file_ron::test_file::{{closure}}
             at ./tests/file_ron.rs:42:16
   7: core::ops::function::FnOnce::call_once
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/ops/function.rs:250:5
   8: core::ops::function::FnOnce::call_once
             at /rustc/9eb3afe9ebe9c7d2b84b71002d44f4a0edac95e0/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

From the error message I conclude that config-rs only supports string keys for maps while the specification of ron also allows non-string keys in maps.
You can check the allowed types for map keys here. The type of a map key is value which you can see here.

I think it would be nice if this crate would also align in that case with the original specification of ron as it caused some troubles for me.

Update:
I just found out that you're already working on making the library more flexible in another repository. That's great news. Can't wait to test it when it's ready!

@matthiasbeyer
Copy link
Collaborator

Hi! Thanks for your report! Changing the config-rs implementation to support non-String keys would be (to my knowlegde) a big undertaking.
I am not sure whether it can be done at all, at least not without major refactoring of the crate I guess.
I hope I can incorporate this into my config-rs-ng efforts...

@polarathene
Copy link
Collaborator

FWIW, I think you'll find deserializing some formats (notably Ron) will be lossy as the format is not deserializing directly into your config struct but being normalized through an intermediary storage.

Supporting the other native rust number formats and types/primitives is probably quite doable vs the Map key concern.

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

No branches or pull requests

3 participants