I'd like to suggest that this change come with a docc improvement that automatically labels unsafe members with a warning box that encourages users to enable StrictMemorySafety
for their module if they plan on using that type/function (much like closure-based callbacks got an async recommendation). This way, StrictMemorySafety
can stay off by default, but almost anyone that looks up unsafe code will see the suggestion to enable these warnings/errors, leading to more adoption across the board.
1 Like