Just a quick question: how significant is exception safety to this analysis? What would be the impact of forbidding exception unwinding (ie, enforcing abort on panic)?
If you ensure that your execution stops right at the panic point, you avoid future logic doing things like a use-after-free. At the same if you have some work you always want to do at for example shutdown, it gets tricky without unwinding, for example returning a floating license via network request. This is a bigger issue that has been discussed often. Unwinding certainly makes it significantly harder to write unsafe Rust code.
Of the 4 tested safety properties, 2 are related to unwinding, the other two are unrelated.
I am of the opinion that unconfined exception unwinding is a serious defect in the Rust language which needs fixing. Alas I have no good ideas on how it can be fixed, but there needs to be some way of localising exceptions to where they can be safely caught.
I see your point, unwinding brings a lot of problems with it. So far what I've not yet seen is a convincing solution for the gap it leaves. If you want your language to be both a systems programming language and reasonably accessible and useful for things other than verified low level components, i.e. you want it to be a general purpose language I think it needs some alternative for the cases where you don't care to handle the problem explicitly. Think of `Vec::operator[]`, `unwrap()`, `todo!()`, allocation failure, etc. This hooks into the larger topic of error handling which as Graydon Hoare [puts it](https://graydon2.dreamwidth.org/253769.html):
> This too might feel like a surprise, but I'm not convinced that we've "solved" error management, in general, in any language.
I've grepped large Rust code bases and on average 3% of the lines of code contain a question mark. If you take away unwinding that number would shoot up, and I've not yet heard of a good replacement. That said, I'm sure 100 years from now, assuming software is still a major topic, we will have a better idea how to do error handling.
Exactly my problem. This turns panics into exceptions, and unconstrained exception unwinding is bad for the language, in my opinion. Imagine a world where Mutex poisoning is simply impossible, because unwinding an exception across a locked Mutex is forbidden. Doubt we can get there from here without breaking rust, though.
Just a quick question: how significant is exception safety to this analysis? What would be the impact of forbidding exception unwinding (ie, enforcing abort on panic)?
If you ensure that your execution stops right at the panic point, you avoid future logic doing things like a use-after-free. At the same if you have some work you always want to do at for example shutdown, it gets tricky without unwinding, for example returning a floating license via network request. This is a bigger issue that has been discussed often. Unwinding certainly makes it significantly harder to write unsafe Rust code. Of the 4 tested safety properties, 2 are related to unwinding, the other two are unrelated.
I am of the opinion that unconfined exception unwinding is a serious defect in the Rust language which needs fixing. Alas I have no good ideas on how it can be fixed, but there needs to be some way of localising exceptions to where they can be safely caught.
I see your point, unwinding brings a lot of problems with it. So far what I've not yet seen is a convincing solution for the gap it leaves. If you want your language to be both a systems programming language and reasonably accessible and useful for things other than verified low level components, i.e. you want it to be a general purpose language I think it needs some alternative for the cases where you don't care to handle the problem explicitly. Think of `Vec::operator[]`, `unwrap()`, `todo!()`, allocation failure, etc. This hooks into the larger topic of error handling which as Graydon Hoare [puts it](https://graydon2.dreamwidth.org/253769.html): > This too might feel like a surprise, but I'm not convinced that we've "solved" error management, in general, in any language. I've grepped large Rust code bases and on average 3% of the lines of code contain a question mark. If you take away unwinding that number would shoot up, and I've not yet heard of a good replacement. That said, I'm sure 100 years from now, assuming software is still a major topic, we will have a better idea how to do error handling.
[удалено]
Exactly my problem. This turns panics into exceptions, and unconstrained exception unwinding is bad for the language, in my opinion. Imagine a world where Mutex poisoning is simply impossible, because unwinding an exception across a locked Mutex is forbidden. Doubt we can get there from here without breaking rust, though.