llvm-d
deadalnix
deadalnix at gmail.com
Thu Mar 28 20:47:45 PDT 2013
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.
More information about the Digitalmars-d-announce
mailing list