3 ms·

It's not about about being able to prevent an infinite loop. It's about being able to say this program really doesn't panic. Which is a very important property.

It's not about about being able to prevent an infinite loop. It's about being able to say this program really doesn't panic. Which is a very important property. For example the Linux Kernel requires Rust code to not panic. There was a lot of work done to ensure this was at all possible. And it wasn't to try and statically assert whether a piece of code panics. It was just disallow panics outright. Do you think these compiler developers just took that route because it's fun? Or because they are "oddly fixated on the halting problem"?

pdimitar 4y ago
I don't know why you are so combative and immediately used the opportunity to reframe what I said above into attacking a good reasonable problem that we would all like eliminated (the halting problem) but I'll ask you to stop because that's not discussing in good faith; you seem to be on the lookout to attack someone and I am seriously not interested in that. -- Having said that: being able to disable / remove `.unwrap` and co. with a compiler flag -- as you seem to imply is the case in the Linux kernel branch of Rust -- would prove hugely beneficial to no small amount of library and app developers. And guaranteeing no panics isn't that hard. Sure the POSIX standard and Linux in particular are vague in many places but I think it's fairly reasonable to be able to guarantee that a program that doesn't use filesystem or network can never panic just through dependency analysis (e.g. no API is used that can propagate a panic from the kernel). How useful would that program be is another discussion entirely though (quite an amusing one at that). My point was and remains that not being able to detect infinite loops is not indicative of the ability to prove that panics [due to system / kernel API carrying them over to you or just straight up blowing up your program] will not occur. And you seem to claim the opposite?

pdimitar 4y ago

I don't know why you are so combative and immediately used the opportunity to reframe what I said above into attacking a good reasonable problem that we would all like eliminated (the halting problem) but I'll ask you to stop because that's not discussing in good faith; you seem to be on the lookout to attack someone and I am seriously not interested in that. -- Having said that: being able to disable / remove `.unwrap` and co. with a compiler flag -- as you seem to imply is the case in the Linux kernel branch of Rust -- would prove hugely beneficial to no small amount of library and app developers. And guaranteeing no panics isn't that hard. Sure the POSIX standard and Linux in particular are vague in many places but I think it's fairly reasonable to be able to guarantee that a program that doesn't use filesystem or network can never panic just through dependency analysis (e.g. no API is used that can propagate a panic from the kernel). How useful would that program be is another discussion entirely though (quite an amusing one at that). My point was and remains that not being able to detect infinite loops is not indicative of the ability to prove that panics [due to system / kernel API carrying them over to you or just straight up blowing up your program] will not occur. And you seem to claim the opposite?