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
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.
That kind of code doesn't have to hurt performance, as long as monomorphic action, 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.
it's more about the fact that the servers are java and invoking a reflection method does have a non-zero cost that isn't substantial but still makes you sigh as you either eat the performance cost or spend 10 minutes creating a patch and recompiling the server.
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.
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.
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.
[0] https://github.com/tsoding/crust
Maybe with time, as more counterexamples are needed for things "you can't just..." in rust.