4 ms·

All compilers allow builds that trigger warnings to complete. Obviously code that only runs when built "debug" differs from released code, which ... doesn't ru

by ncmncm 4y ago

All compilers allow builds that trigger warnings to complete. Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. That is the whole point. Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same. In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period. (I confess it utterly mystifies me how this is such a difficult concept for so many. Inability to comprehend something so simple bodes ill for judgment on more weighty matters.)

aw1621107 4y ago
> All compilers allow builds that trigger warnings to complete. That is true, but I don't see how it's relevant. Violations of the borrowing rules in Rust are like type errors in C++ or C. Warnings are simply not part of the picture. > Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. I honestly don't know what this wording is intended to convey. The text before the edit made more sense. But in any case, I don't really see the relevance. I asked about situations where the presence/absence of optimizations changes language semantics. As far as I know, programmers generally expect that the same code will exhibit the same observable behavior regardless of whether it was built in debug or release mode (i.e., the as-if rule, barring UB/IB/etc., of course). What you're suggesting appears to violate that - something that builds in debug mode may not compile at all in release mode, let alone run the same. How is that better for newcomers? > Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same. This feels like it's doing a lot of hand-waving. By way of analogy: "Before you ship, you resolve all the type nags, and then there will be a release build, and it will run the same" If you started with a program where everything is a void*, "resolve all the type nags" is potentially a huge amount of work. There's absolutely no guarantee that you will only need to make "minor" changes to get your program working in release mode. Maybe what you wrote is good enough, maybe you need to completely restructure your program. That certainly does not sound very newcomer-friendly to me. > In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period. Couldn't this argument be extended to other aspects of a program that can be statically checked? Why stop at the borrow checker?
- ncmncm 4y ago
  You demonstrate that anybody can fail to comprehend anything, howsoever simple, if they dedicate enough effort. What such failure indicates is obscure. (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) It does suggest that the prospect of Rust ever being made more accessible to new users is slim to none, as, thus, is displacing C enough to move any needle, more's the pity. We will need to rely on people graduating to use of modern C++, instead.
  - aw1621107 4y ago
    > (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) No, but again, I don't see the relevance here. What I have been trying to say is simple: tying language semantics to the presence or absence of optimizations is going to pose challenges that could easily overshadow any potential advantages a more "relaxed" debug mode might provide for newcomers. Suggesting that the borrow checker be able to be "turned off" is not novel, but the idea of tying it to optimization level is, and that is what I have been trying to discuss, without much success.
    - ncmncm 4y ago
      If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. Nobody has proposed "turning off" the borrow checker. This is another red herring always thrown up. Nobody has proposed "turning off" the borrow checker. Maybe imagining somebody did is your trouble? But I doubt it. At some risk of triggering another massive incomprehension storm, you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, fixing your const violations before release might be a chore, even a big chore, but it should be very, very easy to imagine other actual program logic problems that might be tackled entirely independently of them. The code with the const violations in might end up deleted, in the process, so that being obliged to fix them first would have been a pure waste of effort.

by ncmncm 4y ago

aw1621107 4y ago

> All compilers allow builds that trigger warnings to complete. That is true, but I don't see how it's relevant. Violations of the borrowing rules in Rust are like type errors in C++ or C. Warnings are simply not part of the picture. > Obviously code that only runs when built "debug" differs from released code, which ... doesn't run. I honestly don't know what this wording is intended to convey. The text before the edit made more sense. But in any case, I don't really see the relevance. I asked about situations where the presence/absence of optimizations changes language semantics. As far as I know, programmers generally expect that the same code will exhibit the same observable behavior regardless of whether it was built in debug or release mode (i.e., the as-if rule, barring UB/IB/etc., of course). What you're suggesting appears to violate that - something that builds in debug mode may not compile at all in release mode, let alone run the same. How is that better for newcomers? > Before you ship, you will resolve all the borrow nags, and then there will be a release build, and it will run the same. This feels like it's doing a lot of hand-waving. By way of analogy: "Before you ship, you resolve all the type nags, and then there will be a release build, and it will run the same" If you started with a program where everything is a void*, "resolve all the type nags" is potentially a huge amount of work. There's absolutely no guarantee that you will only need to make "minor" changes to get your program working in release mode. Maybe what you wrote is good enough, maybe you need to completely restructure your program. That certainly does not sound very newcomer-friendly to me. > In the meantime, you probably have more urgent worries to act on first. The only difference is who decides when, you or the compiler. As is, the compiler decides, period. Couldn't this argument be extended to other aspects of a program that can be statically checked? Why stop at the borrow checker?

ncmncm 4y ago
You demonstrate that anybody can fail to comprehend anything, howsoever simple, if they dedicate enough effort. What such failure indicates is obscure. (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) It does suggest that the prospect of Rust ever being made more accessible to new users is slim to none, as, thus, is displacing C enough to move any needle, more's the pity. We will need to rely on people graduating to use of modern C++, instead.
- aw1621107 4y ago
  > (Is it really so hard to understand how a program that exists and can be executed differs from the entire lack of any such program?) No, but again, I don't see the relevance here. What I have been trying to say is simple: tying language semantics to the presence or absence of optimizations is going to pose challenges that could easily overshadow any potential advantages a more "relaxed" debug mode might provide for newcomers. Suggesting that the borrow checker be able to be "turned off" is not novel, but the idea of tying it to optimization level is, and that is what I have been trying to discuss, without much success.
  - ncmncm 4y ago
    If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. Nobody has proposed "turning off" the borrow checker. This is another red herring always thrown up. Nobody has proposed "turning off" the borrow checker. Maybe imagining somebody did is your trouble? But I doubt it. At some risk of triggering another massive incomprehension storm, you might better compare the suggestion to turning const violations in non-release builds into warnings (while imagining that over-aggressive intolerance of const violations was driving away potential users). Yes, fixing your const violations before release might be a chore, even a big chore, but it should be very, very easy to imagine other actual program logic problems that might be tackled entirely independently of them. The code with the const violations in might end up deleted, in the process, so that being obliged to fix them first would have been a pure waste of effort.