Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve CanonicalAddr interoperability #1463

Merged
merged 4 commits into from
Oct 18, 2022
Merged

Conversation

webmaster128
Copy link
Member

Preparation for #1456 and #1451

@webmaster128 webmaster128 requested a review from uint October 18, 2022 15:02
@webmaster128 webmaster128 force-pushed the CanonicalAddr-conversions branch from 1fe9a37 to e6033ae Compare October 18, 2022 16:09
Copy link
Contributor

@uint uint left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks fine. Is it okay for any arbitrary binary string to be infallibly convertible to CanonicalAddress? The "canonical" sounds like it's supposed to offer some guarantees.

Comment on lines +175 to +180
// Array reference
impl<const LENGTH: usize> From<&[u8; LENGTH]> for CanonicalAddr {
fn from(source: &[u8; LENGTH]) -> Self {
Self(source.into())
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about a slice?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean impl From<&[u8]> for CanonicalAddr? This was already implemented before a few lines above this addition.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, my bad!

@webmaster128
Copy link
Member Author

Is it okay for any arbitrary binary string to be infallibly convertible to CanonicalAddress? The "canonical" sounds like it's supposed to offer some guarantees.

Excellent question. Historically this has always been an unsafe newtype around Binary (with a public field), so at least this is not introducing any new unsafety.

@uint
Copy link
Contributor

uint commented Oct 18, 2022

Excellent question. Historically this has always been an unsafe newtype around Binary (with a public field), so at least this is not introducing any new unsafety.

That's probably fine. I think Rust's Path and PathBuf essentially do the same. I'd just document it.

@webmaster128 webmaster128 merged commit a92b29b into main Oct 18, 2022
@webmaster128 webmaster128 deleted the CanonicalAddr-conversions branch October 18, 2022 20:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants