Open cagedmantis opened 3 days ago
Related Issues
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
To be clear, it may end up that we don't do this at all. I agree with @ianlancetaylor's point that the lack of a trivial migration path makes it hard to justify yammering at people about in IDE pop-ups. It's unfortunate, but given that SetFinalizer
's problems were due to the core API, it might not be worth doing a full deprecation.
Noting here that https://go.dev/wiki/Deprecated is the place where it is documented that:
If function F1 is being replaced by function F2 and the first release in which F2 is available is Go 1.N, then an official deprecation notice for F1 should not be added until Go 1.N+1. This ensures that Go developers only see F1 as deprecated when all supported Go versions include F2 and they can easily switch.
Also that:
Marking an API feature deprecated can create work and decisions for millions of Go developers using the feature. Deprecating an API feature is an API change that must be discussed using the proposal process.
Since deprecation was a part of the accepted proposal #67535 it seems that's done, but if you think this needs more discussion, you might want to take advantage of that process again. Otherwise you can just refer to that existing accepted proposal.
The original intent of proposal #67535 included the deprecation of SetFinalizer. While the proposal is approved and the implementation has landed in the tree, we feel less comfortable with deprecating SetFinalizer in the same release as the addition of AddCleanup. Notibly, the lack of a trivial migration from SetFinalizer to AddCleanup was an issue that was mentioned. This issue intends to track the deprecation of SetFinalizer in a future release of Go and the discussion surrounding it.
@mknyszek @cagedmantis @ianlancetaylor