I usually just box it and then Box::into_raw when I need multiple mutable references in a singlethreaded application where there's no deallocation or cleanup has to occur post shutdown.
though said for education purpose, keep finding these boundary-pushings playful. I can recall early days arrested by "several ways to access private members in C++" lol
Yes. It assumes author of the macro guarantees the safety. Common cases are not adding unsafe{} and leaving this to user, relying on audit tools or [highlighters](https://lukaswirth.dev/posts/semantic-unsafe/), etc. However, it's indeed allowed to silently add unsafe blocks in macros. I'm not working on rust frequently btw, mistakes may exist.
Cool idea. I was expecting more than just turn_off_the_borrow_checker in you_can though.
Maybe with time, as more counterexamples are needed for things "you can't just..." in rust.
I usually just box it and then Box::into_raw when I need multiple mutable references in a singlethreaded application where there's no deallocation or cleanup has to occur post shutdown.
though said for education purpose, keep finding these boundary-pushings playful. I can recall early days arrested by "several ways to access private members in C++" lol
Macros can secretly add "unsafe" blocks into the code?
Yes. It assumes author of the macro guarantees the safety. Common cases are not adding unsafe{} and leaving this to user, relying on audit tools or [highlighters](https://lukaswirth.dev/posts/semantic-unsafe/), etc. However, it's indeed allowed to silently add unsafe blocks in macros. I'm not working on rust frequently btw, mistakes may exist.
Macros are just text in, text out, so yep
This reminds me of Perl's ACME modules and I'm here for that.
Disgusting. I love it.