3 ms·

> 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

> 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.
    - aw1621107 4y ago
      > If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. I mean, if you really want to be pedantic about it, "debug" vs. "release" means precisely nothing since they can be arbitrarily customized. However, in the context of this comment chain (newcomers to Rust), who are likely to be using cargo in its default configuration, "debug" vs. "release" primarily comes down to optimization settings and the generation of debug information, neither of which change program semantics for the most part. The only exception is overflow checking, which is disabled in release mode. While I'll freely admit this does weaken my argument, I assert it doesn't suffer from the main flaw that yours does, in that debug mode is less lenient with respect to overflow checks, and turning them off for release mode doesn't cause compilation errors. This is significantly more friendly to newcomers, though I still think the semantic difference between debug and release is not ideal. > Nobody has proposed "turning off" the borrow checker Nobody in this thread? Sure. Nobody on the Rust dev team? Also sure. I assert (albeit without evidence, unfortunately, though I suspect you know better than I do) that that sentiment is not that uncommon among newcomers, though. In any case, I think you're reading my comment too literally (though that's partially my fault for being unclear). The intended meaning was that adding some way to "bypass" borrow checker errors is not new, whether by literally "turning off" the borrow checker or through some other mechanism as in your proposal. > 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, this is one possible comparison, but as I stated in previous comments, an analogous comparison applies to every other statically-checkable property, and I would argue that they all face the same issue: that what you write in "debug" mode may be unusable in "release" mode, which does not seem like a good experience for a newcomer. In addition, there's the question of why the argument should stop at the borrow checker - why not also have a mode which allows a program to compile despite the compiler complaining about type errors (which is a superset of const violations)? So in the end, yes, I can imagine ignoring one set of problems allowing a programmer to focus on another set of problems. I can also imagine solving one set of problems by ignoring another resulting in an entirely useless solution because the ignored problems are actually/incidentally important, in which case the ability to compile code in an "intermediate" state is cold comfort. Maybe preventing said intermediate code could have clued in the programmer that the solution they were headed towards was unfeasible, as well. Hard to say how this tangle of hypotheticals turns out.

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.
  - aw1621107 4y ago
    > If you really imagine that "debug" vs. "release" building is about optimization, I don't know what to suggest for you. I mean, if you really want to be pedantic about it, "debug" vs. "release" means precisely nothing since they can be arbitrarily customized. However, in the context of this comment chain (newcomers to Rust), who are likely to be using cargo in its default configuration, "debug" vs. "release" primarily comes down to optimization settings and the generation of debug information, neither of which change program semantics for the most part. The only exception is overflow checking, which is disabled in release mode. While I'll freely admit this does weaken my argument, I assert it doesn't suffer from the main flaw that yours does, in that debug mode is less lenient with respect to overflow checks, and turning them off for release mode doesn't cause compilation errors. This is significantly more friendly to newcomers, though I still think the semantic difference between debug and release is not ideal. > Nobody has proposed "turning off" the borrow checker Nobody in this thread? Sure. Nobody on the Rust dev team? Also sure. I assert (albeit without evidence, unfortunately, though I suspect you know better than I do) that that sentiment is not that uncommon among newcomers, though. In any case, I think you're reading my comment too literally (though that's partially my fault for being unclear). The intended meaning was that adding some way to "bypass" borrow checker errors is not new, whether by literally "turning off" the borrow checker or through some other mechanism as in your proposal. > 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, this is one possible comparison, but as I stated in previous comments, an analogous comparison applies to every other statically-checkable property, and I would argue that they all face the same issue: that what you write in "debug" mode may be unusable in "release" mode, which does not seem like a good experience for a newcomer. In addition, there's the question of why the argument should stop at the borrow checker - why not also have a mode which allows a program to compile despite the compiler complaining about type errors (which is a superset of const violations)? So in the end, yes, I can imagine ignoring one set of problems allowing a programmer to focus on another set of problems. I can also imagine solving one set of problems by ignoring another resulting in an entirely useless solution because the ignored problems are actually/incidentally important, in which case the ability to compile code in an "intermediate" state is cold comfort. Maybe preventing said intermediate code could have clued in the programmer that the solution they were headed towards was unfeasible, as well. Hard to say how this tangle of hypotheticals turns out.