you_can::turn_off_the_borrow_checker
37 points
2 days ago
| 6 comments
| docs.rs
| HN
extraduder_ire
29 minutes ago
[-]
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.

reply
himata4113
40 minutes ago
[-]
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.
reply
EFLKumo
35 minutes ago
[-]
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
reply
himata4113
7 minutes ago
[-]
I personally hate access controls in general since it always made be release a big sigh as a I was typing .getClass().getMethod()/getField() knowing that it hurts performance.
reply
codedokode
37 minutes ago
[-]
Macros can secretly add "unsafe" blocks into the code?
reply
kibwen
5 minutes ago
[-]
If you're paranoid, you can use the `forbid(unsafe_code)` attribute, which will produce a compiler error when any code in its scope attempts to use `unsafe`, which includes macro expansions.
reply
EFLKumo
28 minutes ago
[-]
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.
reply
mplanchard
28 minutes ago
[-]
Macros are just text in, text out, so yep
reply
space_ghost
40 minutes ago
[-]
This reminds me of Perl's ACME modules and I'm here for that.
reply
orphea
1 hour ago
[-]
Disgusting. I love it.
reply