3 ms·

It's a little tricky, I think, because lifetimes are a part of the type of things and can determine behavior. But you could possibly do like GHC does with "def

It's a little tricky, I think, because lifetimes are a part of the type of things and can determine behavior. But you could possibly do like GHC does with "defer type errors" and panic if you encounter a situation where that might matter (including before an illegal borrow or whatnot). It doesn't really help you solve the bit that was unchecked, but if you're trying to iterate around something earlier in the code it might be useful sometimes to be able to focus on the bit you're working on and put off cleaning up stuff you're not wanting to execute yet anyway.

aw1621107 4y ago
> But you could possibly do like GHC does with "defer type errors" and panic if you encounter a situation where that might matter (including before an illegal borrow or whatnot). I honestly didn't know that capability existed. Just to make sure I'm reading the right thing, is it the technique described in Equality proofs and deferred type errors: A compiler pearl [0]? I have no training in programming language theory, so I can't give a good evaluation on how applicable this technique is to Rust. The first thing that jumps to mind is that I think it relies on Haskell's laziness to avoid evaluating the thunk (?) representing the type error if it isn't needed, but that's not to say that a different approach can't be found that doesn't require laziness (assuming I read the paper correctly). That being said, given Rust provides types which defer borrowing checks to runtime (Cell/RefCell [1]), I think it may be possible to implement something similar to -fdefer-type-errors by e.g., wrapping all references in a Cell/RefCell and inserting appropriate function calls. I would guess the main concern there is fragmenting the Rust ecosystem into code that requires a hypothetical -fdefer-borrowck-errors flag and code that works with "standard" Rust, and tying that to optimization level has its own issues. It's admittedly a bit different than what I had in mind when I first responded to ncmncm's comment (where I interpreted it as "pretend the borrowck errors didn't exist," as opposed to "use runtime checks as appropriate"), but it does make more sense. Thanks for showing me something new! [0]: https://www.microsoft.com/en-us/research/uploads/prod/2020/02/deferred-icfp12.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/0... [1]: https://doc.rust-lang.org/std/cell/ https://doc.rust-lang.org/std/cell/
staticassertion 4y ago
GCH has a pretty significant head start given that it has lazy semantics and an interpreter. I don't really see the point of disabling the borrow checker anyway. I assume the intent is that it would make incremental development easier, but as someone who has written probably 100kLOC of Rust I feel like it would take a ton of work to implement (ie: making `miri` radically more powerful and generalizing it) and solve... no real problems for me. I get that a beginner is going to see bigger wins there since they will hit borrow checker errors earlier, but even then, I learned rust in 2015 when the borrow checker was way stricter, and I don't think I fought very much with it - I learned immediately that I could clone my way out of almost any issue. IMO a far better investment would be into compiler errors giving better hints, or IDE improvements to show lifetimes, etc, and those would all be global wins instead of something rather niche.

aw1621107 4y ago

> But you could possibly do like GHC does with "defer type errors" and panic if you encounter a situation where that might matter (including before an illegal borrow or whatnot). I honestly didn't know that capability existed. Just to make sure I'm reading the right thing, is it the technique described in Equality proofs and deferred type errors: A compiler pearl [0]? I have no training in programming language theory, so I can't give a good evaluation on how applicable this technique is to Rust. The first thing that jumps to mind is that I think it relies on Haskell's laziness to avoid evaluating the thunk (?) representing the type error if it isn't needed, but that's not to say that a different approach can't be found that doesn't require laziness (assuming I read the paper correctly). That being said, given Rust provides types which defer borrowing checks to runtime (Cell/RefCell [1]), I think it may be possible to implement something similar to -fdefer-type-errors by e.g., wrapping all references in a Cell/RefCell and inserting appropriate function calls. I would guess the main concern there is fragmenting the Rust ecosystem into code that requires a hypothetical -fdefer-borrowck-errors flag and code that works with "standard" Rust, and tying that to optimization level has its own issues. It's admittedly a bit different than what I had in mind when I first responded to ncmncm's comment (where I interpreted it as "pretend the borrowck errors didn't exist," as opposed to "use runtime checks as appropriate"), but it does make more sense. Thanks for showing me something new! [0]: https://www.microsoft.com/en-us/research/uploads/prod/2020/02/deferred-icfp12.pdf https://www.microsoft.com/en-us/research/uploads/prod/2020/0... [1]: https://doc.rust-lang.org/std/cell/ https://doc.rust-lang.org/std/cell/

staticassertion 4y ago

GCH has a pretty significant head start given that it has lazy semantics and an interpreter. I don't really see the point of disabling the borrow checker anyway. I assume the intent is that it would make incremental development easier, but as someone who has written probably 100kLOC of Rust I feel like it would take a ton of work to implement (ie: making `miri` radically more powerful and generalizing it) and solve... no real problems for me. I get that a beginner is going to see bigger wins there since they will hit borrow checker errors earlier, but even then, I learned rust in 2015 when the borrow checker was way stricter, and I don't think I fought very much with it - I learned immediately that I could clone my way out of almost any issue. IMO a far better investment would be into compiler errors giving better hints, or IDE improvements to show lifetimes, etc, and those would all be global wins instead of something rather niche.