tustvold commented on PR #2643:
URL: https://github.com/apache/arrow-rs/pull/2643#issuecomment-1236123998

   I'm not a massive fan of forcing users to choose between slow but correct or 
fast but may have inconsistent behaviour, especially as having parallel kernels 
increases the likelihood of further divergent behaviour...
   
   Taking a step back I wonder if we could just define the overflow behaviour 
as wrapping, and use explicit wrapping_op to avoid signed overflow panics in 
non-release builds. This avoids runtime penalties, is consistent with how Rust 
handles overflow (unlike C++ signed integer overflow is actually defined, the 
debug panics are just "helpful"), and is what I at least would expect to occur.
   
   I'm not sure what SQL says on the topic of overflow, if anything, which may 
be relevant here? Perhaps @alamb knows?


-- 
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