i might revisit the `init&` concept for placement-new, but implementing proper language-level constructors and destructors adds a fuckton of complexity in its own right and i am Not here for it
update: went to prototype this in the compiler and Wow! I Hate The Implications This Has For Every Part Of The Language. no thank you
might just special-case the `mut& self` inside constructor bodies to not assume initialization tbh
i guess i could special-case it??? maybe i could treat `self` as local variable inside the constructor body and just elide the move??? feels like the cleanest solution is to introduce some sort of `init&` for initialization but aarurhggghgh a whole new qualifier for exactly one (1) use case????
the language does have facilities for referencing potentially-uninitialized data, namely `unsafe mut&`, but that's meant to be a C++ interop feature more than anything. kinda hate the idea of using that for constructors tbh!
comune's Definite Initialization impl is robust enough to handle most of the rough edges around C++-style constructors, at least
my main concern is that having the constructor work in-place implies having a `mut&` to uninitialized data, which directly goes against the safety guarantees of `&` and `mut&`
i don't plan on adding copy and move constructors to the equation, but considering some of the planned features for comune, as well as the current state of the trait system implementation, i think having proper constructors and destructors might be a good call here
major RE4 spoilers
i realize this is a spoiler for a nearly 20 year old game, but going into the remake blind? god.
musician, (game)dev, artist, rust nerd, final boss of linux transfems. autism be damned my boy can girl