-
Notifications
You must be signed in to change notification settings - Fork 17
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
Compile-time reflection hashing #72
Comments
Hey @nilres , thanks for taking an interest in the project! As you noticed, we (P2996 authors) were recently considering the introduction of reflection hashing, and from an implementation standpoint it's indeed quite straightforward. Some necessary context for why we decided against it: For P2996, it will not be possible for a reflection to escape its translation unit (i.e., no module or external linkage for a reflection or anything that can "hold" one). This requirement is necessary because a reflection is ultimately an opaque tagged pointer to some compile-time data structure (usually an AST node of some kind). Such pointers are not expected to be stable between TUs. While we think it will be possible in the future to relax this requirement, it requires research into "reconstructing the reflection" on the other side of a module import. In addition with being too busy polishing P2996 to be ready for '26, such experiments are made more difficult because this experimental implementation (i.e., Clang/P2996) is implemented in such a way that breaks modules (fixing this will require some architectural changes to Clang's constant evaluator). So we're very interested in reflections not escaping TUs (at least for P2996) - which brings us to hashes. While we can write language rules to confine reflections to their "home TUs", hashing gives you a means of producing an ..until we realized that neither Hope that helps clear things up! Please follow up with further questions, or close the issue if I've succeeded in addressing them :) |
Amazing background information. Wouldn't it be possible to use "name_of" in the same way? The name might not be fully unique making it a bad "hash" but still it is a way to sneek out information across multiple TUs isn't it? Not saying this is a good argument to introduce an explicit hash but something to keep in mind. |
Yep, it would certainly be possible to build a "mostly unique representation" using the other libraries provided - but the author of that representation will be able to ensure that it has the properties needed for their application. For instance, they might only need hash representations of class types having external linkage, in which case it should suffice to hash the name of the class, and do the same walking up |
With 97ce63b compile time hash generation was introduced which I really liked as an replacement for projects like https://github.com/Manu343726/ctti which provide similar functionality but in a unelegant way.
I don't know if the hash implementation is part of any of the current proposals but personaly I would find it quite useful.
Maybe you could explain why you removed it a couple of commits later.
Greetings
Nils
The text was updated successfully, but these errors were encountered: