Skip to content

Conversation

@tomcur
Copy link
Contributor

@tomcur tomcur commented Dec 3, 2025

No description provided.

Copy link
Contributor

@waywardmonkeys waywardmonkeys left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be better as a struct-struct with 2 fields rather than a tuple struct?

Copy link
Contributor Author

@tomcur tomcur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this be better as a struct-struct with 2 fields rather than a tuple struct?

Yes, that makes sense. There may also be value in thinking about the memory layout a bit, to allow methods like id_is_newer to be compiled down to a single u64 comparison without requiring any shifting of memory (this type is a likely target for exposing through FFI in the future, I think, so it'll get repr(C) anyway). In Vello sparse we do some cfg based on endianness, but potentially here we can decide to just do the optimization assuming the target is little endian.

@tomcur tomcur force-pushed the named-nodeid-access branch from bcadd80 to bcb76ac Compare December 4, 2025 10:24
Copy link
Contributor Author

@tomcur tomcur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've given the struct named fields, but haven't made them pub (yet?) for two reasons: first, the idx() method casts to usize, which may be nice to keep for ergonomics, regardless of the exact internal representation. Second, we may still want to have a deterministic layout / packing of this struct, but perhaps we need to think more about the "ID is newer" semantics: that's currently based on generation first, which is perhaps fine for just having a deterministic ordering, but generations are only meaningfully comparable if the node has the same idx (as generation tends to be tracked per-idx).

@waywardmonkeys
Copy link
Contributor

Overall, this is the right thing ... but feel like maybe we need to think about some of these details a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants