個人的に気になったのは“Bunsafe”……何でもないです
実際に“bunsafe”で検索すると`\bunsafe\b`が引っかかるという（？）
all of rust codebase: This codebase fails even the most basic miri checks, allows for UB in safe rust · Issue #30719 · oven-sh/bun
https://github.com/oven-sh/bun/issues/30719
該当のコードを見るとどうもポインタをprovenance抜きの整数として扱っているようだからそりゃ不健全なわけだけど、元のZigのコードではこれで健全だったりしたのかね
他の言語のコードから等価な(unsafe) Rustのコードに変換するというタスクにおいては古典的にもCにおけるC2Rustのような例があったわけで、ZigにおいてAIを使って同様に移植できましたというだけでは言うほどの新規性はあるのかなという感想。
既存のテストケースが通ったと言っても、それはとりあえず既存のコードの振る舞いは再現できたというだけの話であって、本当に問題になるのはそのコードを起点に今後の開発において今までと同等以上のメンテナンス性やら安定性やら何やらを達成できるかなのではないかと思うけど、そういった意味では現時点ではまだどうなるのかよく分からんね
（研究ではないのだから別に新規性なんて要らないのだけど、話題の上がり方に何か全く革新的な出来事と捉えるような向きを（勝手に）感じたのでこういう表現になった（補足））
全てが実質unsafe相当の言語よりもunsafeまみれのRustの方がマシという（ありがちな）主張については、Safe Rustが安全であるということが正しく保証されているのならばそうなのかもしれないけど、safeのフリをした不健全なコードまみれの場合はその保証が破られているわけだから話が違ってくるよなあ。
Safeとunsafeの境界が正しく分けられているのならばそこから漸進的にunsafeの範囲を狭めていくアプローチが効くけど、“safe”コードの領域が実際には不健全性に汚染されているのだとすれば、そのままその領域を押し広げても嬉しくはない
