toml

Quoted strings with a newline on the first line (including Windows ) called , which decremented from 1 to 0. then indexed . Keep at 1 when the error is still on the first line, and clamp the snippet indexes in . Fixes #517

Fixes #517. always did , but only bumps the line on . For a CRLF/bare-CR newline inside a string on line 1 that drove to 0 and panicked in with . Only decrement when the consumed byte was (same idea as ). Added covering LF/CRLF in basic and literal strings.

Proposal I would like to propose an opt-in mechanism for decoding polymorphic TOML tables based on a type discriminator. For example: could be represented as: With: And: Motivation The important part is that the concrete type can be resolved before decoding the table. Instead of: the decoder can do: This avoids decoding the same data twice and allows the existing TOML decoder to handle all fields normally. The resolver only determines the destination type; the existing decoder remains responsible for decoding the contents. The behavior would be explicitly opt-in through TypeProvider, leaving existing decoding behavior unchanged. I would be interested in feedback on whether this API fits the library and whether there is a preferred way to integrate the type-resolution step into the existing decoder.