Yeah, the argument in #329 (comment) doesn't that make much sense tbh. However, I still stand by the argument that the option to emit struct names does not belong in PrettyConfig because it makes a difference when deserializing, unlike the other options in PrettyConfig.

Ok, that argument sounds more reasonable :)

@MomoLangenstein I think this interacts with your PR #343, right? Any thoughts on how to incorporate both these PRs?

@MomoLangenstein I think this interacts with your PR #343, right? Any thoughts on how to incorporate both these PRs?

Yes, it does! I think that this would be a fantastic option to add to the Options builder. If this PR gets merged first I could make that refactor (or I could just get my PR merge-ready more quickly). One interesting aspect would be what this option means for deserializing. It could have no impact (which would fit RON not being self-describing), or it could enforce that struct names are provided. I would prefer the former as I could imagine that many would like output nice and clear RON but also allowing more inference during deserialisation. And the point of #343 is kind of that you use the same options for both ser and de.

Sounds good to me! I'm wondering if we even need to expose any kind of *_advanced function with so many parameters, would probably be simpler with the Options API then.

Sounds good to me! I'm wondering if we even need to expose any kind of *_advanced function with so many parameters, would probably be simpler with the Options API then.

That's a good point. Right now I feel like there shouldn't be more convenience functions. I like that when you just want to get RON running you only need from_str and to_string. I feel like once you want more than just those very simple default cases, you can just initiate the Serializer or Deserializer directly.

I don't plan to take this any further, closing.