Add try_newtype_datatype! for fallible domain conversions#21
Merged
Conversation
`newtype_datatype!` handles infallible `Owned -> Newtype` conversions.
`try_newtype_datatype!` is its fallible sibling, for newtypes that
`impl TryFrom<Owned>` (the build direction, `From<Newtype> for Owned`,
stays infallible).
Consistent with `Column`'s "validate once at construction, then read
infallibly" contract, every value is checked eagerly in `downcast`
(`Column::try_new` and derive parsing). A rejected value stops there,
boxing the `TryFrom` error into the new `ColumnError::Conversion`,
surfaced as the new `ErrorKind::Conversion { column, source }` once the
column name is known.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
These are all TryFrom a primitive quiver already supports (infallible back), so they slot straight into try_newtype_datatype!: - NonZeroI8..I64, NonZeroU8..U64, stored as their plain integer - char, stored as UInt32 (surrogates/out-of-range rejected) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related
What
newtype_datatype!handles infallibleOwned -> Newtypeconversions. This addstry_newtype_datatype!, its fallible sibling, for newtypes thatimpl TryFrom<Owned>— the build direction (From<Newtype> for Owned) stays infallible. TheTryFrom::Errormust bestd::error::Error + Send + Sync + 'static.Consistent with
Column's "validate once at construction, then read infallibly" contract, every value is checked eagerly indowncast(Column::try_newand the derive's record-batch parsing). A rejected value stops there, boxing theTryFromerror into the newColumnError::Conversion, surfaced as the newErrorKind::Conversion { column, source }once the column name is known. After construction, element access stays infallible.Same
noref/primitivearm options asnewtype_datatype!.Testing
fallible_newtype_columnsintegration test (Even/NotEvennewtype): build via infallibleFrom, borrowed + owned reads,primitivebulkas_slice, eager rejection attry_new→ColumnError::Conversion,Option<Even>null-skipping, andErrorKind::Conversionviafrom_record_batch_and_name.cargo clippy --all-features --all-targetsclean;cargo test --all-featuresgreen.Compatibility
Additive: new macro plus new non-exhaustive-style variants on
ColumnErrorandErrorKind. Both enums already carried multiple variants; downstream exhaustivematches on them would need the new arm.🤖 Generated with Claude Code