Add a way to customize the literal-ness (single/double quotes) of a string
sunshowers opened this issue · 2 comments
Hi everyone (and epage in particular), thanks for all your hard work on toml! Really appreciating all the work y'all have done integrating toml_edit and toml.
For guppy, tried upgrading toml to 0.7 and sadly ran into a deal-breaking issue. Guppy currently produces output that has single quotes in it, e.g. this file. When I migrate to toml 0.7, it becomes double-quoted as seen in https://gist.github.com/sunshowers/0ed4ab2143ea1efa8afb10f1a500e61e#file-gistfile0-txt-L4-L28.
The output format cannot be changed for backwards compatibility reasons -- these files are checked into repositories and one of the promises made by hakari is to not change how checked-in files are recorded.
So it seems like what I would need is a way to change how strings are recorded so that they're presented as single quotes.
I spent some time looking around and it looks like while this is supported internally, there's no API to access this. Value::String is a Formatted<String>, which doesn't seem to be high-enough fidelity. It seems like what we would really need is a StringWithQuotes or similar, which would track both the string as well as the quoting style.
What do you think? Without this, or some other solution, I'll have to be stuck at toml 0.5 forever. This would be a shame :(
Huh, looks like this is the first time someone has requested customizing of strings.
If backwards compatibility on formatting is important for you, I would recommend auditing for it any auto formatting because we do not guarantee compatibility on it.
I spent some time looking around and it looks like while this is supported internally, there's no API to access this. Value::String is a Formatted, which doesn't seem to be high-enough fidelity. It seems like what we would really need is a StringWithQuotes or similar, which would track both the string as well as the quoting style.
The way this would be handled is
impl Formatted<String> {
pub fn style(&mut self, ...);
}Which would overwrite the Repr stored inside the Formatted to preserve the information
I'm fine with doing this, we just need to work out the details of the API and make sure the string formatting is hardened enough to support this. By keeping it internal, I'm less likely to run into corner cases like someone over-specifying a string style that cannot be used.
If backwards compatibility on formatting is important for you, I would recommend auditing for it any auto formatting because we do not guarantee compatibility on it.
Absolutely, we have a number of tests which catch issues related to backwards compatibility (not just formatting, but also ordering of table entries, and so on). Those tests are how I found out about this issue.