3 ms·
There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really a
by chiffaa 7mo ago
There are ways to handle these effects without bloating up normal applications. For example, using attributes implemented as intrinsics, which wouldn't really affect anything that isn't using them.
The thing is, some of these things are very useful in specific domains, and all these domains are closely related to the ideas of safety. Nondeterminism and IO are important for purity/referential transparency, which is a fairly important effect for business logic IMO. Guaranteed termination matters for formal verification. Unwind removal matters for embedded. I don't think wishing for these things is really all that unwarranted
> I actually don’t see how this is any more beneficial than the existing no_panic macro
no_panic and similar macros are doing a very hacky workaround which isn't really a great static guarantee. The simple fact that building with panic = abort makes the macro useless is an annoyance in and of itself. dtolnay did great when figuring out some path forward but it's somewhat shaky
- dtolnay 7mo agoIf a piece of code does not panic in panic=unwind, then it does not panic in panic=abort either. So having coverage of panic=unwind would be sufficient to guarantee that code cannot panic. The caveat you mention with panic=abort would only apply to code that is unable to build for panic=unwind, which is uncommon.
- chiffaa 7mo agoOh, then I misremembered and misunderstood the note, my apologies On that note, thank you for all your work!