Az unsafe nem az jelenti, hogy az adott programrész feltétlenül bajt csinál, hanem azt, hogy arra a részre nem tud a compiler garanciát adni. Mert garanciát akkor tud adni, ha a matematikai konstrukció amire a biztonság bizonyítása épül mindenütt be van tartva. Az unsafe-re a programozónak kell garanciát adnia, nagyjából ott van ahol C-ben lenne: vannak eszközei amikkel lehet hibás és hibátlan programot is írni.
Általában két céllal hozzák létre az unsafe dolgokat:
Egyik a teljesítmény növelése, amire nagyon ritkán, de szükség lehet. Azért mondom, hogy ritkán, mert a teljesítmény növelésére persze mindig szükség van, de többnyire nem ez a szűk keresztmetszet. Ritka az olyan program ami már annyira optimális, hogy már csak unsafe-fel lehet javítani rajta. De van ilyen és szükség van rá, akkor lehet.
A másik pedig a virtuális gép szabályainak nem megfelelő dolgok használata, ami lehet például egy másik nyelvbe belehívás, vagy perifériák memóriájának közvetlen írása. Ez az amire vélhetően a "versenyben" szükség volna.
Összefoglalva az unsafe azt jelenti, hogy a biztonságosságot a compiler és a runtime nem tudja garantálni, mert a bizonyítás logikájába bele nem férő módon történik a működés. De ettől még az a kód lehet biztonságos, csak azt a programozó egyéb módszerekkel kell hogy garantálja.
Nem hinném, hogy valódi probléma volna, hogy a kezdők értelmetlenül használnák az unsafe konstrukciót. Nem lesz attól egyszerűbb semmi, egyáltalán nem erről szól ez a kulcsszó. És ha mondjuk egy kernelt fejleszt valaki Rustban, akkor abban lesz fix számú unsafe, és azt ki lehet listázni a kódból és hozzá lehet mindegyikhez rendelni egy magyarázatot, hogy miért szükséges használni, és mi garantálja, hogy megfelelően működik. És az unsafe nem azt jelenti, hogy az egész programban deaktiválva vannak a védelmek, hanem csak pont abban a kis részben.
Az pedig továbbra is áll, hogy nyilván nem lesz egy kezdő szarja jó attól, hogy Rustban van, arra viszont mégis garanciát ad a nyelv, hogy a memória a virtuális gép szabályainak megfelelően fog működni. Tehát ha nem kap referenciát a kezdő programozó függvénye a b változóra, akkor annak az értékét nem tudja átírni semmilyen módon.
Egy c programban, ha 1 függvényt használsz, ami nem tuti, akkor megtörténhet, hogy felülírja az isLaunchingNuclearRocketImminent változó értékét igazra. Akkor is, ha a függvény feladata csak vonalkód nyomtatás lett volna valójában, de mondjuk valaki számok helyett betűket is írt a mezőbe, ami az átalakítás során overflowolt, és épp ez a változó csücsült ott. Ilyen Rustban nincsen, nem lehetséges. Ezt a hibaosztályt megszünteti a biztonságos memória menedzsment. De nem csak a Rustra igaz ez, számtalan nyelv régóta tudja, a Java és a .NET is ilyen volt már a kezdetektől (90-es évek), Quora szerint a BCPL volt az első nyelv, amiben biztonságos pointerek voltak.
>Azt gondolom, ez a kizárás oka, csak nincs minden egyes feltétel hosszas körmondatokkal megmagyarázva.
Ennek semmi értelme nem lenne, mert a funkcionalitás maga, például JavaScriptben megírva kb egysoros volna. Semmi értelme nincsen a probléma logikáján belül unsafe-t használni valakinek, aki tudja hogyan kell Rustot programozni. A tiltás értelme pontosan az, hogy a Rust unsafe nélkül csak Rustot tud hívni, hiszen ami kívül esik az ő VM-jén az számára nem safe. Tehát fából vaskarika unsafe nélkül a kírás. Olyan mint az, hogy "Vágjátok ki az erdő legnagyobb fáját! Ezzel a heringgel!" És ezt vagy tudja bzt és akkor nem fair a kiírás, vagy nem tudja, és akkor meg olyat kritizál amit nem ismer. Vagy lehet az is, hogy a C-be híváshoz nem kell az unsafe kulcsszó, de attól még az ugyanaz. Például Java-ban a native kulcsszó jelöli a JVM-ből kilépő hívást, amivel például C libraryt lehet hívni. Tehát nem unsafe a neve, de attól még az persze unsafe, mert a JVM nem tudja ellenőrizni, hogy odakinn ki mit hogyan fog felülírni.