4 ms·

Will it be possible to set some flag in Cargo.toml or in compiler arguments to enforce "saturating" behavior everywhere is possible? (even by price of some perf

Will it be possible to set some flag in Cargo.toml or in compiler arguments to enforce "saturating" behavior everywhere is possible? (even by price of some performance degradation).

eridius 11y ago
Why would you want that? "saturating" behavior is something you want only rarely. It certainly isn't something you want to use by default for arithmetic operations.
- zzzcpan 11y ago
  How about just different operators for different intents? Like prepending a special symbol in front of an operator to make it behave differently.
  - eridius 11y ago
    The article already mentioned the idea of using separate operators to control this behavior, similarly to how Swift has a separate set of operators for wrapping arithmetic.
  - pcwalton 11y ago
    That's discussed in the article. "The current state isn’t necessarily the final state of overflow checking: the RFC even mentioned some future directions. Rust could introduce operators like Swift’s wrapping +% in future, something that was not done initially because Rust tries to be conservative and reasonably minimal, as well as hypothetically having scoped disabling of overflow checking (e.g. a single function could be explicitly marked, and its internals would thus be unchecked in all modes). There’s interest in the latter particularly, from some of Rust’s keenest (potential) users Servo and Gecko."
    - zzzcpan 11y ago
      Yes, I know. But more operators is the solution, it removes all that ambiguity with multiple intents and simplifies a lot of things.
  - masklinn 11y ago
    There are already methods for all intents, and while (as noted in TFA) it's possible wrapping gets an operator, it's really unlikely that saturating or checked would get one.
- EugeneOZ 11y ago
  Because I'm sure it's the behavior I want to use 99% of the time, and rest 1% is same behavior just with some warning, not breaking execution flow. I'm not asking it to be default, just flag. Thanks for moving discussion out of my question...
  - eridius 11y ago
    It sounds to me like you probably misunderstand what "saturating" arithmetic is. It certainly is not the behavior you want for 99% of your arithmetical code. It is really quite rare to actually want that behavior.
    - EugeneOZ 11y ago
      Please explain me two things: 1. Why you think I'm too stupid to read documentation? 2. Why you think you know what I want?
- sjolsen 11y ago
  >"saturating" behavior is something you want only rarely. Well, yes, because what you almost always actually want is the mathematically accurate result. Failing that, though, I can think of a few cases where you would want overflow to saturate (hardware outputs, mostly); I haven't thought of any cases yet where wrapping would be remotely useful.
  - alextgordon 11y ago
    Literally the definition of the integers is that (x + 1) != x. Wrapping is bad enough, but at least tends to makes failures noticeable. Saturating arithmetic makes it really hard to see that a failure has occurred. Depending on the performance penalty you're willing to take, there's good alternatives to wrapping, such as: A) 64-bit integers, B) bigints, C) crashing on overflow. Sure, saturation might be useful in certain circumstances, like manipulating audio samples, but it's generally something you want to make explicit. Using it everywhere? It's madness!
    - EugeneOZ 11y ago
      How easy it is to decide for others if they are mad or not, even not asking them about details... No worries, I'm not proposing it as default for all, I was just asking if it's possible to set as flag for some programms.
    - vardump 11y ago
      Say you're computing a buffer size with untrusted inputs. With saturated arithmetic, you could add the (unsigned) sizes together without a possibility of an overflow, so you could eliminate all except the last range check (=branch). If the end result is larger than what is reasonable, return an error. It's not possible that the value wrapped around and later code will be writing to unallocated memory.
      - eridius 11y ago
        That doesn't actually eliminate range checks. Hardware doesn't have native saturating overflow operations so the saturating overflow methods are implemented by doing a checked overflow and using the min/max value of the type if it overflows/underflows. Which is to say, it removes them from your code, but there's no performance benefit to it.
dbaupp 11y ago
There's no flag to enforce saturation, although as discussed in the article and above, saturation isn't as nice as wrapping in several ways (in particular, errors do not cancel out like they do with wrapping).

Will it be possible to set some flag in Cargo.toml or in compiler arguments to enforce "saturating" behavior everywhere is possible? (even by price of some performance degradation).

eridius 11y ago

Why would you want that? "saturating" behavior is something you want only rarely. It certainly isn't something you want to use by default for arithmetic operations.

zzzcpan 11y ago
How about just different operators for different intents? Like prepending a special symbol in front of an operator to make it behave differently.
- eridius 11y ago
  The article already mentioned the idea of using separate operators to control this behavior, similarly to how Swift has a separate set of operators for wrapping arithmetic.
- pcwalton 11y ago
  That's discussed in the article. "The current state isn’t necessarily the final state of overflow checking: the RFC even mentioned some future directions. Rust could introduce operators like Swift’s wrapping +% in future, something that was not done initially because Rust tries to be conservative and reasonably minimal, as well as hypothetically having scoped disabling of overflow checking (e.g. a single function could be explicitly marked, and its internals would thus be unchecked in all modes). There’s interest in the latter particularly, from some of Rust’s keenest (potential) users Servo and Gecko."
  - zzzcpan 11y ago
    Yes, I know. But more operators is the solution, it removes all that ambiguity with multiple intents and simplifies a lot of things.
- masklinn 11y ago
  There are already methods for all intents, and while (as noted in TFA) it's possible wrapping gets an operator, it's really unlikely that saturating or checked would get one.
EugeneOZ 11y ago
Because I'm sure it's the behavior I want to use 99% of the time, and rest 1% is same behavior just with some warning, not breaking execution flow. I'm not asking it to be default, just flag. Thanks for moving discussion out of my question...
- eridius 11y ago
  It sounds to me like you probably misunderstand what "saturating" arithmetic is. It certainly is not the behavior you want for 99% of your arithmetical code. It is really quite rare to actually want that behavior.
  - EugeneOZ 11y ago
    Please explain me two things: 1. Why you think I'm too stupid to read documentation? 2. Why you think you know what I want?
sjolsen 11y ago
>"saturating" behavior is something you want only rarely. Well, yes, because what you almost always actually want is the mathematically accurate result. Failing that, though, I can think of a few cases where you would want overflow to saturate (hardware outputs, mostly); I haven't thought of any cases yet where wrapping would be remotely useful.
- alextgordon 11y ago
  Literally the definition of the integers is that (x + 1) != x. Wrapping is bad enough, but at least tends to makes failures noticeable. Saturating arithmetic makes it really hard to see that a failure has occurred. Depending on the performance penalty you're willing to take, there's good alternatives to wrapping, such as: A) 64-bit integers, B) bigints, C) crashing on overflow. Sure, saturation might be useful in certain circumstances, like manipulating audio samples, but it's generally something you want to make explicit. Using it everywhere? It's madness!
  - EugeneOZ 11y ago
    How easy it is to decide for others if they are mad or not, even not asking them about details... No worries, I'm not proposing it as default for all, I was just asking if it's possible to set as flag for some programms.
  - vardump 11y ago
    Say you're computing a buffer size with untrusted inputs. With saturated arithmetic, you could add the (unsigned) sizes together without a possibility of an overflow, so you could eliminate all except the last range check (=branch). If the end result is larger than what is reasonable, return an error. It's not possible that the value wrapped around and later code will be writing to unallocated memory.
    - eridius 11y ago
      That doesn't actually eliminate range checks. Hardware doesn't have native saturating overflow operations so the saturating overflow methods are implemented by doing a checked overflow and using the min/max value of the type if it overflows/underflows. Which is to say, it removes them from your code, but there's no performance benefit to it.

dbaupp 11y ago

There's no flag to enforce saturation, although as discussed in the article and above, saturation isn't as nice as wrapping in several ways (in particular, errors do not cancel out like they do with wrapping).