Is Leader::Default really implemented

[fredericd]

This line of Rust code :

let mut record = Record::new(Leader::default());

generates :

associated function or constant not found in `Leader, MarcError>`

[dchud]

Confirmed, and thank you for the report — you found a real gap, not a usage mistake.

Leader genuinely has no Default implementation. There is no derive, no manual impl, and no default associated function in src/leader.rs. The only ways to construct one were Leader::from_bytes(&[u8]), which returns Result<Leader, MarcError>, and a bare struct literal of all thirteen public fields. (The Leader, MarcError> fragment in your paste is the tail of rustc's suggestion pointing at from_bytes — your code block got clipped before the closing fence.)

The reason a nonexistent constructor is all over the documentation is worse than the missing impl itself. Leader::default() appears in 34 doc examples across 11 modules, and every one of them sits inside an ```ignore fence. cargo test --doc therefore never compiled them, while docs.rs renders them as ordinary Rust. So the published documentation was advertising an API that had never existed, and CI was structurally unable to notice.

#449 fixes both halves:

• impl Default for Leader in the core crate, using the values the Python binding has always produced (n/a/m, indicator and subfield-code counts of 2, reserved 4500). PyLeader::new now delegates to it so the two layers cannot drift apart again.
• 119 of the 120 ignored doctests in src/ are now compile-checked. That surfaced several more examples documenting methods that do not exist or take different arguments than shown — Field::get_subfields shown taking varargs, FieldQuery::indicator2 shown taking a bare char, Record::matching_fields (the method is fields_matching), RdfGraph::to_string, and MarcReader used as an iterator. All corrected.

cargo test --doc goes from 34 passing / 120 ignored to 153 passing / 1 ignored, so this specific class of documentation rot now fails CI instead of reaching users.

Until that lands, the working form on 0.9.2 is Leader::from_bytes(b"00000nam 2200000 4500")?, or a struct literal if you want to set positions explicitly.

[dchud]

One refinement since the comment above. The Python binding had always set leader position 09 to a space (MARC-8), and my first pass carried that value into the new Default. That was wrong, so #449 now sets it to a (Unicode) instead.

MarcWriter serializes field values as UTF-8 and the ISO 2709 write path has no MARC-8 branch, so a default leader declaring MARC-8 described an encoding mrrc never emits — build a record with any non-ASCII content and it went out mislabelled. Leader::default() now renders as 00000nam a2200000 4500.

The broader problem, that the writer ignores position 09 entirely rather than honouring or correcting it, is tracked separately.