Follow naming conventions

Choose names that follow established API conventions and guidelines to create a consistent, intuitive codebase:

1. For conversions or views:
   • Use as_* for cheap, reference-based conversions

     // Prefer this
     fn as_socket(&self) -> socket2::SockRef<'_> {
       socket2::SockRef::from(self)
     }
     // Instead of
     fn to_socket(&self) -> socket2::SockRef<'_>
     

2. For clarity through qualified names:
   • Prefer context-specific names over generic ones

     // Prefer this
     pub fn sender_strong_count(&self) -> usize
     // Instead of
     pub fn strong_count(&self) -> usize
     

   • Use semantic descriptors over technical ones

     // Prefer this
     pub fn notify_one_last_in(&self)
     // Instead of
     pub fn notify_one_lifo(&self)
     

3. When using plurals in parameters:
   • Make method names reflect plurality

     // Prefer this
     pub async fn copy_bidirectional_with_sizes<A, B>
     // Instead of
     pub async fn copy_bidirectional_with_size<A, B>
     

4. Avoid naming conflicts:
   • Don’t add methods with the same name as trait implementations when your type implements Deref
   • For similar functionality, use qualified names

     // Prefer this
     pub fn clone_inner(&'static self) -> T
     // Instead of
     pub fn clone(&'static self) -> T  // Confusing with Clone trait
     

Even when verbosity increases, prioritize clarity and prevention of API confusion. AbortOnDropHandle may be verbose, but it clearly communicates the type’s behavior.