Module reader 

Reading a document: the seam between text and this crate’s tree.

A reader answers one question — what does this text say, in this format? — and answers it with a Value. Everything above it works on that tree and never on a parser, which is what lets the parser be a choice.

"[db]\nport = 5432\n"  +  Format::Toml   ──▶  {db: {port: 5432}}

Three ship, and the reason to choose between them is not taste:

reader	feature	parses	notes
native() — the default	—	JSON, TOML, YAML, INI, .properties	the only .properties parser anywhere
config_rs()	—	JSON, TOML, YAML, INI, RON, JSON5	YAML through the maintained yaml-rust2
figment()	figment	JSON, TOML, YAML

The column is what each one parses, not what a load that chose it can read: a format the chosen reader has no parser for is handed to one that has — so choosing config_rs() for its YAML does not cost you the .properties file beside it.

Unlike the engines, readers are not interchangeable down to the corner. A fold is one rule with an implementation on each side; a parser is a dialect, and two YAML libraries disagree about things no specification settles. What the tests hold is the part a deployment depends on — the shapes documents actually take — and the places they diverge are named in the book rather than papered over.

Which one runs is the same choice the engine is: Builder::reader, LoadSpec::with_reader, or set_reader once for the process.

Traits

Reader

Text in, this crate’s tree out.

Functions

all

Every reader this build ships, this crate’s own first.

config_rs

The config crate’s parsers.

figmentfigment

The figment crate’s parsers.

has_reader

Whether a reader has been installed.

native

This crate’s own parsers.

set_reader

Installs reader for every load in this process that does not name one.