I did not suggest to change the behavior of env::remove_var like that, and I would not be in favor of such a change.
1 Like
One issue with deprecated_safe: there could be existing uses of these functions in unsafe blocks (and, in particular, in unsafe fn, which are unsafe blocks by default) -- and those users would not get any notification that there now is a new safety condition to uphold.
I do not have a good suggestion for resolving this, other than actually deprecating the old functions and introducing new, unsafe functions under new names.
Arguably the safety condition has always existed; it's just documented now.
Arguably this definitely had no safety condition before, since it was a safe function. The fact that this spec was wrong doesn't change that this is the spec we communicated to our users, so cleaning up this mess is on us.
So I think you are making a distinction without a difference -- people have written code assuming these functions have no safety condition, and we had documentation which said that this is okay. Now it turns out it's not okay and people need to revisit their code. Making the functions unsafe in-place will not ensure that all code is revisited.
In some sense this is worse than mem::uninitialized, I think.
5 Likes