-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add generic Ref, Deref and Equal to the pointer package #269
Conversation
Ahhh, actually, this seems to be against the policy https://github.com/kubernetes/community/blob/master/sig-architecture/generics.md#generics-policy |
/hold /lifecycle frozen |
@alculquicondor: The In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Are we doing generics in utils now? |
No, we are not yet, because we still support Kubernetes versions that do not use generics yet. The tentative plan is to permit generics when 1.24 is out of support (or earlier, but only in k/k / staging, not in shared libraries that cross release boundaries). https://github.com/kubernetes/community/blob/master/sig-architecture/generics.md |
I think the comments above already note that and are holding the PR until that time though? |
I missed that. Mea culpa. |
The guidance is now adjusted to the EoL for 1.23, which is on |
func Int(i int) *int { | ||
return &i | ||
// Ref returns a pointer to the value. | ||
func Ref[T any](v T) *T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not "New" ptr.New[int64](12345)
is as close as we can get to &int64(12345)
or new(int64, 12345)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I liked how complementary Ref
and Deref
sounded. But New
would work too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about To
? pointer.To(12345)
seems even nicer to me...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pointer.New()
, pointer.To()
, pointer.P()
would all be fine to me. We could even rename the pkg to ptr
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we? I guess we would need to duplicate the package first.
But we are still waiting for 1.24 to go EoL next month.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It wouldn’t have to be duplicated — you could add a generic ptr
package, and change pointer
to be full of vars pointing to ptr
functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One benefit of introducing a new generic ptr
package instead of updating the existing pointer
package would be to simplify migration tracking: any references to utils/pointer
would point (hah) to code that should be updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree.
@skitt would you like to take over? The time for adding these generics is coming next month, and I honestly have limited time to do so.
I can simply close this PR and you can start over with the ptr
package approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can take care of this, yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome
/close
FWIIW, 1.23 is using golang 1.19 now, but I don't think there was a release with it, yet. |
For sure there has been a release with 1.18 kubernetes/kubernetes#113983 @BenTheElder, can we lift the restriction? |
cc @liggitt |
Actually, there hasn't... 1.23 jumped from go1.17 to go1.19 in that PR and doesn't yet have a patch release on that (will be in January's releases). I still think we should still wait until 1.23/1.24 are out of support since library consumers can still be on the original go minor versions those were released with |
But if they upgrade the libraries they would need to upgrade golang, or not necessarily? |
No, building / testing 1.23 client-go examples with go1.17 and 1.24 with go1.18 still works. |
So we're NOT accelerating this? Just confirming. |
That would be my vote. I think we should stick to the original timeline, so we don't put ourselves in a position where a bump of k8s.io/utils in the 1.23 or 1.24 release branch would force a library consumer to update go versions on a patch bump. |
But 1.24 was originally released with go=1.18, which supports generics. So we should good to start using generics when 1.23 goes EoL. |
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Still holding until July, to my understanding? /remove-lifecycle stale |
} | ||
// IntPtr is a function variable referring to Int. | ||
// | ||
// Deprecated: Use Int instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might as well point to Ref
(or New
or To
) directly since that’s what people updating deprecated code should end up using.
} | ||
// IntPtrDerefOr is a function variable referring to IntDeref. | ||
// | ||
// Deprecated: Use IntDeref instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here: this might as well point to Deref
directly. (Same goes for all the other instances.)
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alculquicondor The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@alculquicondor: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This simplifies the implementation and adds support for pointers to enums and arbitrary types. To allow a complete migration from pointer to ptr, this also moves AllPtrFieldsNil. The ptr.AllPtrFieldsNil "ptr" repetition is preserved since the function only looks at pointer fields. Existing deprecation notices are updated to point to the new functions, but the remaining pointer functions aren't deprecated (yet) to avoid having a large amount of imposed changes in downstream projects where linting forbids deprecated functions. Existing test code is preserved as-is to "prove" the correctness of the migration. This was mostly written by Aldo Culquicondor; see kubernetes#269 for context. Signed-off-by: Stephen Kitt <skitt@redhat.com>
This simplifies the implementation and adds support for pointers to enums and arbitrary types. To allow a complete migration from pointer to ptr, this also moves AllPtrFieldsNil. The ptr.AllPtrFieldsNil "ptr" repetition is preserved since the function only looks at pointer fields. Existing deprecation notices are updated to point to the new functions, and the pointer package as a whole is deprecated. Existing test code is preserved as-is to "prove" the correctness of the migration. This was mostly written by Aldo Culquicondor; see kubernetes#269 for context. Signed-off-by: Stephen Kitt <skitt@redhat.com>
What type of PR is this?
/kind feature
What this PR does / why we need it:
Add Ref, Deref and Equal that use generics. This simplifies implementation and also allow to have pointers of enums or arbitrary types.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: