add basic_toml_conf feature

[JeromeSchmied]

add feature to migrate from the massive toml dependency to it's light-weight hard fork (now unmaintained, but functional) basic-toml. AFAIK it supports most toml syntax, except for date-time

[JeromeSchmied]

maybe as non-default feature?

[JeromeSchmied]

does this look good, or should I fork?

[deg4uss3r]

Overall I would be okay adding this in, do you have any metrics for what this move would save the average developer (compile times, binary size, etc)?

I don't think I have ever reached for basic_toml over toml before. I can also talk to @epage to see if toml-rs would be interested in taking in basic_toml since it was very recently unmaintained.

[epage]

In abstracting the use of basic-toml from the user, you should probably make it clear that

• Its unmaintained
• It is non-conformant

Keep in mind dtolnay created basic-toml to reduce the build times of trybuild and then dropped it in dtolnay/trybuild#239, in part because of dtolnay/trybuild#257

With those caveats, I would personally think it questioable to support but then again, I maintain the name of the crate it was forked from (it was forked from toml 0.5 and toml 0.6 was a complete rewrite).

I don't think I have ever reached for basic_toml over toml before. I can also talk to @epage to see if toml-rs would be interested in taking in basic_toml since it was very recently unmaintained.

I have no interest in maintaining it. Part of my condition for taking on maintaining toml was that I wouldn't be maintaining multiple TOML parsers but could consolidate them.

I am playing with a new parser implementation for toml_edit that may reduce some of the overhead (including possibly being usable outside of toml_edit and directly by toml). This is all an experiment that is very much a low priority (usually while I'm traveling to conferences).

[JeromeSchmied]

thanks for the info, I understand this basic_toml is definitely not usable in many cases, but IMO and use-case being so simple amd lightweight is highly admirable, even in it’s current state, not evolving anymore - of course only if one knows the trade-offs as they’re properly documented - especially when someone chooses this crate over the quite complete config-rs

as for the refactors and docs, I’ll look into them next week as they’re reasonable