>>110258923
i dont think its 'wrong' ive used things like keeping multiple arrays of pointers to the same heap memory in C arranged in different ways which wouldnt work as easily in rust.
having a language that doesnt allow that blocks you from using code which would otherwise by 100% valid. rust does what i think is a wise tradeoff in making the more complicated path more awkward to write and making the 'nicer' more orderly way of writing the same code easy to write and compile-time-checked far more thoroughly than say C code.
you can still do the thing you do in C like
let s1 = String::from("some text");
let s2 = unsafe { String::from_raw_parts(s1.as_ptr() as *mut u8, s1.len(), s1.capacity()) };
println!("s1: {s1}, heap location: {:p}", s1.as_ptr());
println!("s2: {s2}, heap location: {:p}", s2.as_ptr());
std::mem::forget(s2);
which prints
s1: some text, heap location: 0x563817921d50
s2: some text, heap location: 0x563817921d50
but it looks retarded and needs an 'unsafe block' + assembling the second string part by part + you need to run 'forget' on one of them so rust doesnt do a double-free.
i like the design philosophy and this isnt what i thought it was when ive been hearing people talking about rust. i think in 95% of cases the solution where you dont do things like this and just let the compiler handle deallocation thats a better, less complicated,more readable and more maintainable solution.
