you_can::turn_off_the_borrow_checker

https://docs.rs/you-can/latest/you_can/attr.turn_off_the_borrow_checker.html

by striking • 2 months ago

54 22 2 months ago

orphea• 2 months ago

Disgusting. I love it.

himata41133• 2 months 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.

space_ghost• 2 months ago

This reminds me of Perl's ACME modules and I'm here for that.

tmtvl• 2 months ago

I would go for a Rust version of Acme::Bleach.

codedokode• 2 months ago

Macros can secretly add "unsafe" blocks into the code?

mplanchard2• 2 months ago

Macros are just text in, text out, so yep

estebank3• 2 months ago

Rust macros are Token Trees and provide namespace hygiene, so not quite "text in, text out".

EFLKumo2• 2 months 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.

kibwen• 2 months 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.

EFLKumo2• 2 months 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

himata41133• 2 months 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.

estebank3• 2 months ago

That kind of code doesn't have to hurt performance, as long as monomorphization, inlining or JITting are available to the toolchain. If every single method access is a virtual-table call, then yes, there's an "unnecessary" cost. But you shouldn't be writing high-level looking code in such a language if you care about that level of performance.

extraduder_ire• 2 months 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.

rurban• 2 months ago

Even more unsafe rust, great!

tempesttempo86• 2 months ago

Arbitrary mention: Crust[0]

[0] https://github.com/tsoding/crust

nextaccountic• 2 months ago

Wow, it really do look like C

https://github.com/bext-lang/b/blob/main/src/bgen.rs

Pesthuf• 2 months ago

I wonder if this has any measurable impact on compile times.

wasmperson• 2 months ago

Rust's memory safety is as much a social convention as it is a language feature. The language has something better described as "mutation safety," and it's the job of library developers to use that to design UB-free APIs.

I think many people understand this subconsciously, and that this is what drives some of the more performative security culture in Rust spaces (superfluous safety comments, shunning of certain crate authors, `forbid(unsafe)`, push-back against syntax sugar, etc.).

you_can::turn_off_the_borrow_checker

Related Stories