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

Make #[derive(Debug)] output compatible with ron #550

Open
HKalbasi opened this issue Oct 29, 2024 · 3 comments
Open

Make #[derive(Debug)] output compatible with ron #550

HKalbasi opened this issue Oct 29, 2024 · 3 comments

Comments

@HKalbasi
Copy link

This makes ron useful in deserializing output of programs using default Debug trait of Rust.

@juntyr
Copy link
Member

juntyr commented Oct 30, 2024

Do you mean making RON fully compatible with Rust syntax?

@HKalbasi
Copy link
Author

I mean making the output of #[derive(Debug)] a subset of ron syntax, so I can use println!("{:?}", value) in addition to normal serializing.

For example, X { a: 1, b: 2 } should be accepted in addition to the current X ( a: 1, b: 2 ). There is no need to drop support for the current form to make it Rust syntax compatible.

@juntyr
Copy link
Member

juntyr commented Oct 30, 2024

This may be possible to do. Ron has syntax for maps (since ron is a superset of JSON), so { a: 1, b: 2 } would be parsed as a map from an enum with variants a and b to ints. I mention this because Ron usually supports omitting struct names. But if we require including the struct name for this syntax, it may be possible.

Do you want to submit a PR for this feature? This syntax addition would likely be feature-gated. Enabling the feature during serialisation would use the new syntax for structs (and struct-like enum variants), and enabling it during deserialisation would allow using the new syntax.

My guess is that it may be as simple as modifying the current deserialize_struct impl (and its variant counterpart). If the struct name was found, it could peek for an opening curly brace and then expect a closing curly brace later, otherwise it would use the current parsing rules. The logic for guessing struct types in deserialize_any would also need to be amended (this case would actually be quite simple to handle).

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
@HKalbasi @juntyr and others