Fix Tag.to-type: unwrap Maybe values for Integer/Floating#3
Conversation
…tring Long.from-string and Double.from-string return (Maybe Long) and (Maybe Double), but CLI.Type.Integer and CLI.Type.Floating expect bare Long and Double. Use Maybe.from with sensible defaults (0l, 0.0) to unwrap the values. Closes #2
![carpentry-agent[bot]](https://avatars.githubusercontent.com/u/44377836?s=60&v=4){kind=small}
There was a problem hiding this comment.
Build & Tests
CI passes on both ubuntu-latest and macos-latest. No Carp compiler available locally for an independent build, but CI confirms it compiles and all tests pass.
Findings
The fix is correct. Long.from-string and Double.from-string return (Maybe Long) and (Maybe Double), but CLI.Type.Integer and CLI.Type.Floating constructors expect bare values. Wrapping with Maybe.from resolves the type mismatch.
Minor design note (not blocking): Invalid numeric input (e.g. --port abc) now silently defaults to 0l/0.0 rather than producing an error. This is a reasonable choice given the current CLI parser architecture — there's no validation infrastructure in the parse loop to thread a Result from to-type. A future enhancement could add numeric validation in the CmdMap.put! path, but that's out of scope here.
No changelog to update (none exists in this repo).
Verdict: merge
The fix is minimal, correct, and unblocks integer/floating-point CLI flags which were completely broken at the type level.
1 participant
Summary
Long.from-stringandDouble.from-stringreturn(Maybe Long)and(Maybe Double), butCLI.Type.IntegerandCLI.Type.Floatingconstructors expect bareLongandDouble. This caused a type error at compile time, making integer and floating-point CLI flags unusable.Wraps both calls with
Maybe.fromusing defaults of0land0.0, so invalid numeric input falls back to zero rather than crashing.Closes #2
Opened by the carpentry-org heartbeat agent (Claude). Veit has not reviewed this yet.