v0.8.1

Release v0.8.1

Predictable option collection for registered structs

gonf now assembles struct-level task options in a single, documented order — no matter how those options are attached. The same struct declaration always produces the same effective settings, and obvious declaration mistakes are reported clearly at registration time instead of surfacing as confusing errors later.

Fixed

• Consistent collection order. Options supplied through a StructTaskOptions method (defined on the struct, or promoted from an embedded marker) could previously be combined at a different point in the sequence than options from embedded markers, contradicting the documented "markers first, then Opts()" order. Because order matters when several sources set the same option, this could silently change a task's effective settings. Collection now always follows one sequence: embedded markers in declaration order, then the Opts() companion, with the StructTaskOptions fallback consulted only when a struct declares no marker fields. A regression test locks this behavior in.
• One well-defined path for method-supplied options. Whether a struct's StructTaskOptions method applies no longer depends on a "only if nothing else was collected" check, which could mix or drop option sources in edge cases. The method's role is now explicit: it is used exactly when the struct has no embedded marker fields, so its options are never silently lost or unexpectedly combined with other sources.

Improved

• Fail fast on malformed methods. StructTaskOptions must be declared as func() TaskOptions — the same contract as Opts(). Wrong signatures now cause a clear, explicit panic at registration instead of an opaque error deep inside option collection, making typos and refactoring slips much easier to catch.

Behavior changes and migration notes

• Embed option markers as exported types. Unexported embedded markers are now deliberately skipped during collection. Their options are still honored through the promoted method, but only when the struct has no other marker fields — if a struct mixes exported and unexported markers, the unexported one's options are no longer applied. Exporting the embedded marker type resolves this.
• Review structs combining Opts() with StructTaskOptions. The relative order of those two option sets changed. If such a struct relies on one set overriding the other, verify its effective settings after upgrading and move options between the two sources as needed.

No action is required for structs that already embed markers as exported types and do not mix Opts() with StructTaskOptions.