Rafferty97 commented on code in PR #9418:
URL: https://github.com/apache/arrow-rs/pull/9418#discussion_r2928017509


##########
arrow-buffer/src/bigint/mod.rs:
##########
@@ -807,6 +807,46 @@ impl Shr<u8> for i256 {
     }
 }
 
+impl WrappingShl for i256 {
+    #[inline]
+    fn wrapping_shl(&self, rhs: u32) -> i256 {
+        (*self).shl(rhs)

Review Comment:
   The dereference isn't necessary, and I think the wrapping behaviour should 
be explicit rather than delegated to the `shl` implementation. i.e.:
   
   ```
   impl WrappingShl for i256 {
       fn wrapping_shl(&self, rhs: u32) -> Self {
           // Truncating to a `u8` masks off the higher-order bits as required
           self.shl(rhs as u8)
       }
   }
   ```



##########
arrow-buffer/src/bigint/mod.rs:
##########
@@ -807,6 +807,46 @@ impl Shr<u8> for i256 {
     }
 }
 
+impl WrappingShl for i256 {
+    #[inline]
+    fn wrapping_shl(&self, rhs: u32) -> i256 {
+        (*self).shl(rhs)
+    }
+}
+
+impl WrappingShr for i256 {
+    #[inline]
+    fn wrapping_shr(&self, rhs: u32) -> i256 {
+        (*self).shr(rhs)
+    }
+}
+
+// Define Shr<T> and Shl<T> for specified integer types
+macro_rules! define_wrapping_shift {

Review Comment:
   I'm not sold on the idea of implementing `Shl`/`Shr` with wrapping 
semantics, as this is inconsistent with the other built-in integer types, which 
panic instead.



##########
arrow-buffer/src/bigint/mod.rs:
##########
@@ -807,6 +807,46 @@ impl Shr<u8> for i256 {
     }
 }
 
+impl WrappingShl for i256 {
+    #[inline]
+    fn wrapping_shl(&self, rhs: u32) -> i256 {
+        (*self).shl(rhs)
+    }
+}
+
+impl WrappingShr for i256 {
+    #[inline]
+    fn wrapping_shr(&self, rhs: u32) -> i256 {

Review Comment:
   Similarly, I'd suggest:
   
   ```
   impl WrappingShr for i256 {
       fn wrapping_shr(&self, rhs: u32) -> Self {
           // Truncating to a `u8` masks off the higher-order bits as required
           self.shr(rhs as u8)
       }
   }
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to