Meta: Link to here from #100 and remove things about metadata.
[ ] decide if we should use a better (less general, …) name for this format if possible
[x] remove floating-point numbers from the specification (and placeholders from the implementation if there are any)
[x] remove versions and version specifications from the format
[ ] design string escape sequences, multi-line strings and raw string (and implement it)
[x] heavily improve the deserialization API (via 2360544279fb1676f88dedc3093b0c90f714fb4a)
[x] we don't want to manually remove elements from a map or an array and loop through any remaining entries to error on but
we'd like to have some Vec::drain-like function/method that returns an iterator maybe or something higher-level (and the option to only warn on unknown keys)
[ ] write a basic specification
[ ] obviously containing a motivation for the existence of the format (comparison with JSON (no comments), YAML (too complex, unsafe), TOML (weird array-of-object syntax, bad with nesting), all of the above: no Rust libraries with good Span API for diagnostic integration as far as I checked)
[x] decide if we want to add a serialization/stringification API and implement it if we want to have it
motivation: lushui new currently uses a a big string literal and format to create the initial package.metadata file which is error-prone
decision: no such API
wasn't worth the complexity, wasn't flexible enough for lushui new: "keys in insertion order", "extra blank lines for clarity"
Meta: Link to here from #100 and remove things about metadata.
Vec::drain-like function/method that returns an iterator maybe or something higher-level (and the option to only warn on unknown keys)SpanAPI for diagnostic integration as far as I checked)motivation:lushui newcurrently uses a a big string literal andformatto create the initialpackage.metadatafile which is error-pronelushui new: "keys in insertion order", "extra blank lines for clarity"