3 ms·

The point isn't that there is a bug, it's that you haven't told the compiler enough information about what to do. It's kind of like writing a generic function

The point isn't that there is a bug, it's that you haven't told the compiler enough information about what to do. It's kind of like writing a generic function signature and asking it to fill in the blank when there are many ways that can be done all with different semantics. Haskell has type holes which cause a runtime error when executed as they cannot be evaluated which is an interesting approach (it also has other uses, such as figuring out types).

josephg 5y ago
Exactly. The borrow "checker" is misnamed. Its part of the compiler. You can't skip borrowck and still produce a working executable for the same reason you can't skip linking. Hm. Or can you? It might be possible to make a special "leaky" rust compiler mode where: - Your program is only allowed to be single-threaded - Nothing ever gets dropped. (All allocated memory leaks). And all variables get put on the heap. - Mutable references can alias That might be enough to make rust's lifetimes irrelevant. But I'm not convinced the juice is worth the squeeze. If you don't mind segfaults, you could make it useful by copying C's semantics instead - but you'd need to manually free memory to avoid memory leaks. Or if you also don't care about performance and rust's ffi, you could put a tracing GC in there. But if you want that, why not just use Zig or Go?
- ncmncm 5y ago
  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 being altered will have almost all its borrows neatly lined up.
  - 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.

josephg 5y ago

Exactly. The borrow "checker" is misnamed. Its part of the compiler. You can't skip borrowck and still produce a working executable for the same reason you can't skip linking. Hm. Or can you? It might be possible to make a special "leaky" rust compiler mode where: - Your program is only allowed to be single-threaded - Nothing ever gets dropped. (All allocated memory leaks). And all variables get put on the heap. - Mutable references can alias That might be enough to make rust's lifetimes irrelevant. But I'm not convinced the juice is worth the squeeze. If you don't mind segfaults, you could make it useful by copying C's semantics instead - but you'd need to manually free memory to avoid memory leaks. Or if you also don't care about performance and rust's ffi, you could put a tracing GC in there. But if you want that, why not just use Zig or Go?

ncmncm 5y ago
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 being altered will have almost all its borrows neatly lined up.
- 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.