Rename conversion functions on Address type
What the developer wrote
Authored by Mitchell Bagot
Rename conversion functions on Address type
According to the Rust API naming guidelines, type conversion functions
that convert from owned -> owned on Copy types should be named with a
to_ prefix. Only owned -> owned conversions for non-Copy types should
use an into_ prefix.
Rename into_unchecked to to_unchecked, and into_inner to to_inner in
Address implementation.
What changed, and why it matters
This commit is a routine code cleanup that renames some internal conversion functions on the Address type to follow Rust naming conventions. It does not change what the code does, only what the functions are called. The old names are kept as aliases that show a deprecation warning so existing users are not broken.
No security action needed. This is a non-functional API naming refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The patch renames Address::into_inner to Address::to_inner and Address::into_unchecked to Address::to_unchecked, because Address is Copy and owned-to-owned conversions on Copy types should use the to_ prefix per Rust API guidelines. The old into_unchecked is retained as a #[deprecated] public wrapper. All internal call sites are updated. There is no behavioral or security-relevant change.
Changed components
bitcoin/src/address/mod.rsInspect captured patch +12 / −6
diff --git a/bitcoin/src/address/mod.rs b/bitcoin/src/address/mod.rs
index 196f74ad..d065105f 100644
--- a/bitcoin/src/address/mod.rs
+++ b/bitcoin/src/address/mod.rs
@@ -442,7 +442,7 @@ impl<'de, U: NetworkValidationUnchecked> serde::Deserialize<'de> for Address<U>
{
// We know that `U` is only ever `NetworkUnchecked` but the compiler does not.
let address = v.parse::<Address<NetworkUnchecked>>().map_err(E::custom)?;
- Ok(Address::from_inner(address.into_inner()))
+ Ok(Address::from_inner(address.to_inner()))
}
}
@@ -465,7 +465,7 @@ impl<V: NetworkValidation> serde::Serialize for Address<V> {
impl<V: NetworkValidation> Address<V> {
fn from_inner(inner: AddressInner) -> Self { Address(PhantomData, inner) }
- fn into_inner(self) -> AddressInner { self.1 }
+ fn to_inner(self) -> AddressInner { self.1 }
fn inner(&self) -> &AddressInner { &self.1 }
@@ -475,8 +475,14 @@ impl<V: NetworkValidation> Address<V> {
}
/// Marks the network of this address as unchecked.
+ pub fn to_unchecked(self) -> Address<NetworkUnchecked> {
+ Address::from_inner(self.to_inner())
+ }
+
+ /// Marks the network of this address as unchecked.
+ #[deprecated(since = "0.33.0", note = "use to_unchecked instead")]
pub fn into_unchecked(self) -> Address<NetworkUnchecked> {
- Address::from_inner(self.into_inner())
+ Address::from_inner(self.to_inner())
}
/// Returns the [`NetworkKind`] of this address.
@@ -898,7 +904,7 @@ impl Address<NetworkUnchecked> {
/// For details about this mechanism, see section [*Parsing addresses*](Address#parsing-addresses)
/// on [`Address`].
#[inline]
- pub fn assume_checked(self) -> Address { Address::from_inner(self.into_inner()) }
+ pub fn assume_checked(self) -> Address { Address::from_inner(self.to_inner()) }
/// Parses a bech32 Address string
pub fn from_bech32_str(s: &str) -> Result<Address<NetworkUnchecked>, Bech32Error> {
@@ -993,10 +999,10 @@ impl<U: NetworkValidationUnchecked> FromStr for Address<U> {
if ["bc1", "bcrt1", "tb1"].iter().any(|&prefix| s.to_lowercase().starts_with(prefix)) {
let address = Address::from_bech32_str(s)?;
// We know that `U` is only ever `NetworkUnchecked` but the compiler does not.
- Ok(Address::from_inner(address.into_inner()))
+ Ok(Address::from_inner(address.to_inner()))
} else if ["1", "2", "3", "m", "n"].iter().any(|&prefix| s.starts_with(prefix)) {
let address = Address::from_base58_str(s)?;
- Ok(Address::from_inner(address.into_inner()))
+ Ok(Address::from_inner(address.to_inner()))
} else {
let hrp = match s.rfind('1') {
Some(pos) => &s[..pos],
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.