You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The argument must be a pointer of any type or an unsafe.Pointer. It must be the result of calling new, taking the address of a composite literal, or taking the address of a local variable. If one of these conditions is not met, Pin will panic.
However, it does not always do so today.
A channel, map, or slice value can be constructed by calling make, which does not involve a call to new, nor a composite literal, nor the address of a local variable. Empirically, Pin does not panic when called on such an object (https://go.dev/play/p/q_iyNHJduRf).
It isn't clear to me whether this is a mistake in the documentation (a valid case that was omitted from the doc comment), or a bug in the implementation (Pin failing to panic for an unsupported address).
At a higher level, it seems to me that it is basically always a mistake for a doc comment to state that something will panic for an unsupported input, since that makes it an incompatible change to ever add support for such an input. (It would be better for Pin not to promise anything about what happens for such an input, but to panic anyway as a debugging aid to the user.)
The text was updated successfully, but these errors were encountered:
See #62356 and CL 527156，After CL 527156, the documentation becomes:
The argument must be a pointer of any type or an unsafe.Pointer. It's safe to call Pin on non-Go pointers, in which case Pin will do nothing.
We only usually backport fixes for regressions, so I'm inclined to leave this one be. Pin will panic less in 1.22 than in 1.21, but that's not so bad. It isn't like Pin in 1.21 panics more than 1.20 (because Pin doesn't exist in 1.20).