-
Notifications
You must be signed in to change notification settings - Fork 326
Do not pretend to default initialize a device lambda #5015
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
base: branch-25.06
Are you sure you want to change the base?
Conversation
Found in CCCL CI
VertexValueInputIterator vertex_value_input_first{}; | ||
VertexOp v_op{}; | ||
vertex_t local_vertex_partition_range_first; | ||
VertexValueInputIterator vertex_value_input_first; |
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't we default initialize iterators as well? Or is this because of possible thrust::transform_iterator with lambda?
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.
My reasoning with removing all default initializers is that partially initializing the struct does not make any sense and it is only ever initialized in a single place, so it feels "cleaner" to initialize all or nothing
Nothing I feel strongly about though
vertex_t local_vertex_partition_range_first{}; | ||
VertexValueInputIterator vertex_value_input_first{}; | ||
VertexOp v_op{}; | ||
vertex_t local_vertex_partition_range_first; |
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 think we can default initializing vertex_t (which is either int32_t or int64_t) or can this be also problematic?
Found in CCCL CI