Skip to content
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

Consider using field names for anonymous types/unions #2759

Open
HadrienG2 opened this issue Feb 12, 2024 · 2 comments
Open

Consider using field names for anonymous types/unions #2759

HadrienG2 opened this issue Feb 12, 2024 · 2 comments

Comments

@HadrienG2
Copy link

HadrienG2 commented Feb 12, 2024

While they have a good chance of avoiding namespace collisions, numbered anonymous types are decidedly not very readable.

image

It would be nice if bindgen could use the field name instead when naming the anonymous type. In the above example, hwloc_bridge_attr_s__bindgen_ty_1 would become hwloc_bridge_attr_s__upstream and hwloc_bridge_attr_s__bindgen_ty_2 would become hwloc_bridge_attr_s__downstream.

@pvdrz
Copy link
Contributor

pvdrz commented Apr 3, 2024

My first impression is that this is a good idea. My main thoughts on the subject are:

  • There might be name collisions if two structs have fields with the same name. So that means that we cannot drop the number suffix at the end in all cases.
  • This is a breaking change. It could be a welcome one as it could reduce the breaking changes in libraries using bindgen (if we manage to drop the number at the end of the type unless is required).
  • The internal changes required to achieve this might be larger than expected if we don't have the name of the field while deciding the name of the type.

TLDR: Sounds like a desirable thing, just needs someone implementing so we can figure out small details that might come up.

@HadrienG2
Copy link
Author

There might be name collisions if two structs have fields with the same name. So that means that we cannot drop the number suffix at the end in all cases.

Sorry, I did not understand this part. Can this really happen if the type name contains the name of the struct as a prefix, as in my proposal? In my mind, if hwloc_bridge_attr_s::upstream is a unique entity in C (and it should be), then there is no reason why a matching autogenerated hwloc_bridge_attr_s__upstream Rust type name shouldn't be unique.

Okay, technically, a C library could have another type using the same naming convention (literally a struct hwloc_bridge_attr_s__upstream {};), but who does that? ;)

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

No branches or pull requests

2 participants