Idea: Safe blocks for inside unsafe blocks

huh... this makes me wonder if saftey/unsaftey should be linked to macro hygine, actually.

1 Like

I would much prefer that to safe blocks.

Macros are already hygienic with respect to the edition of the code, so a similar mechanism could be used (?)

The reason I'm a little against safe blocks is that allowing the layering of unsafe and safe makes it harder to decide at a glance if a particular line is unsafe, which is kind of the point of having unsafe blocks in the first place.

2 Likes

Macro hygienic safety has one major issue with the straightforward behavior: unsafe macros. Currently, if a macro calls unsafe API without an unsafe block internally, that can be discharged by a block outside the macro call. But if safety is fully hygienic, that no longer can be done.

So the actually desirable behavior of allowing unsafe blocks to "enter" macro expansions but not "exit" the macro is still possible, but it's much less obviously correct.

2 Likes

Reasoning by analogy with how it works for regular functions: Would this be adequately addressed by allowing one to write unsafe macro_rules!, creating a macro that could only be called from within an unsafe block?

Whether the body of an unsafe macro automatically counts as inside an unsafe block should depend on the existing unsafe_block_in_unsafe_fn lint (RFC for unsafe blocks in unsafe fn by RalfJung · Pull Request #2585 · rust-lang/rfcs · GitHub).

1 Like