3 ms·

Way to miss the point. The program that is coded all in one go before ever compiling, and then never altered after, is rare as unicorns. Any working program b

• deleted 5y ago
  [deleted]
• josephg 5y ago
  > The program that is coded all in one go before ever compiling, and then never altered after, is rare as unicorns. What? I never said that. Its bit rich to say I've missed the point, then immediately misinterpret me. > Any working program being altered will have almost all its borrows neatly lined up. Sure. My question is: When the lifetimes don't make sense, what should the compiler do if its expected to produce running code all the same? Should it leak memory? Should it produce code with undefined behaviour - like use-after-free errors and race conditions? You seem to want code thats been explicitly marked as invalid by the borrow checker to still run. The rust compiler isn't designed to do that, and I'm trying to think through how the compiler could make invalid code run at all. What should even happen if you try to use a variable after handing over ownership?
  • ncmncm 5y ago
    Absolutely it should leak memory, if that is what it takes to get a program hobbling along. This is a debug build, we already know it doesn't work right, yet. If we didn't know before, the warning told us. No program is going to ship with whatever bug it allows in, so who cares? The overwhelming majority of your undefined behaviors have no effect on what the person is interested in, right at that moment. They will get around to your crisis on their own time. You are just insisting that your crisis be vanquished before they are allowed to look into theirs.
    • zanellato19 5y ago
      You then have two different languages. Its not a trivial decision to simply "leak" memory as you are saying. What happens with files? Do you corrupt the files? Do you not close TCP connections? What you are proposing is to Rust to have two languages inside the same compiler. I guarantee you people would simply put debug builds in production if they could "turnoff" the borrow checker like you are proposing.
      • ncmncm 5y ago
        Do you X? Sure, why not? I am not suggesting anything even vaguely like what you are saying. The compiler should emit whatever the code it sees says to emit. If it neglects to arrange to close TCP connections, they won't be closed. So what? I am not interested in TCP connections right now, or I would patch up that bit, in response to the warning the compiler spit out. I have other things to worry about right then. The release build will insist everything be taken care of, so there is no "other language". You are just permitted to get there by a route you choose, in place the route Cargo would impose now.
    • nightski 5y ago
      Having worked some in Rust, and a lot in Haskell in my experience the design changes because of the borrow checker/type system (fixing the issues will provoke re-design, mostly for the better). Meaning it's not something you just flip on after the fact. The types can help guide and drive the design. They aren't a straitjacket to be taken off once code whack a mole is done. That said, I do think Rust could add something like Haskell's type holes where instead of just randomly leaking memory the code has undefined behavior and will simply crash the program if executed.
      • ncmncm 5y ago
        Nobody suggested "flipping it off after the fact", whatever that would mean. I have no idea where you are getting this.