Description
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!