On Thursday, 28 March 2013 at 19:09:47 UTC, Moritz Maxeiner wrote:
No problem, if you mean a strict/strong type, iirc (correct me if I'm wrong, though) that is the case for C enums as well. I can change the alias to typedef, though, if it is really that important.
Typedef is depreacted. The D way is enum TypeName : superType { members }
Generally I would agree, but I'm translating the declarations of an interface here, not porting the implementation. And as such the content of the D interface imho should match the content of the C interface, meaning a literal translation, even if that makes it stupid from the D perspective. The *only* exception to that is the file structure as C headers are different things than D modules and there's no 100% match in D for C headers. D interface files (.di) would probably be technically the closest thing.
Changing the module structure change the interface. Including all isn't a solution to that problem, as this kind of thing will make compile time and resource explode, especially since many things here are built out of mixins.
Your enum choice would create a break in the documentation, as the enum items would not match what is written in the LLVM doxygen documentation anymore (which means I would have to provide documentation for that difference); that also holds true for the file structure, of course, but since you'll get the entire C API with one import anyway ("import llvm.c.all") there's no additional documentation needed there (it is covered by the already existing examples).
It wont break LLVM's documentation. See for instance : http://llvm.org/docs/doxygen/html/group__LLVMCCoreType.html
LLVMGetTypeKind is clearly documented as returning a LLVMTypeKind, not an int.
If you want proper D enums (with names), though, they'll be present in the D API - mapping to the C bindings' enum's items.
Code duplication is rarely a good idea. Especially since your goal mentioned above is to reduce maintenance costs.
