-1
I don’t think @available is an appropriate way to convey this information. Yes, a separate attribute would work very similarly, but there are many things with identical implementations that should nevertheless be separate.
Reusing the implementation behind the scenes in a compiler would be fine, but they should be distinct at the language level.
I’m not entirely convinced that this even needs a language feature. Given the difficulty of actually checking this, and the expected rarity of use, couldn’t this simply be handled by expecting problematic code to name itself “unsafe” and document the requirement?
I would also like to point out, as others already have, that this seems to overlap considerably with the @noLocks attribute from the performance roadmap, and that has the benefit of being more descriptive.