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
Currently userData is an object, which means that to store a struct or value type it needs to be boxed.
Perhaps it could be changed to an int, long, or pointer?
I understand the convenience aspect, especially for array indexing.
However, I think adding int/uint overloads would increase the API surface without providing much real benefit.
B2UserData is intentionally modeled around long / ulong to keep the type semantics explicit and consistent.
Since GetSigned() and GetUnsigned() already exist, consumers can easily cast to int or uint at the call site when needed.
Adding additional overloads for narrower integer types also opens the door to further type proliferation, which I’d prefer to avoid to keep the API simple and intention-revealing.
Activity
ikpil commentedon Jan 18, 2026
That’s a great point. I’ve created a new branch to implement these changes. I’ll give it a try now.
wip #80
refactor: Change `userData` type to avoid boxing #80
cmann1 commentedon Jan 19, 2026
Looks good, thanks.
refactor: Change `userData` type to avoid boxing #80
ikpil commentedon Jan 19, 2026
I’ve made the changes and merged them. Could you please take a look?
cmann1 commentedon Jan 19, 2026
Awesome thanks it works perfectly.
Perhaps int/uint overloads for convenience since they're commonly used for indexing arrays?
ikpil commentedon Feb 8, 2026
I understand the convenience aspect, especially for array indexing.
However, I think adding int/uint overloads would increase the API surface without providing much real benefit.
B2UserData is intentionally modeled around long / ulong to keep the type semantics explicit and consistent.
Since GetSigned() and GetUnsigned() already exist, consumers can easily cast to int or uint at the call site when needed.
Adding additional overloads for narrower integer types also opens the door to further type proliferation, which I’d prefer to avoid to keep the API simple and intention-revealing.