llvm-d

[Moritz Maxeiner]

On Thursday, 28 March 2013 at 05:04:42 UTC, deadalnix wrote:
>
> Ok, that sound reasonable.
>
> Second question, why do you do stuff like :
>
> enum Foo {
>    FooA,
>    FooB,
>    FooC,
> }
>
> when you would do
>
> enum Foo {
>     A,
>     B,
>     C,
> }
>
> ?

I don't, I do:

alias uint Foo;
enum : Foo
{
   FooA,
   FooB,
   FooC
}

which is a direct translation of the C enums. It gives the enum 
items no named scope, only creates an (alias) type for them. See
https://github.com/Calrama/llvm-d/blob/master/llvm/c/constants.d
and
https://github.com/Calrama/llvm-d/blob/master/llvm/c/types.d

>
> D enums introduce a scope, when C's don't. So C need to prefix 
> enums entries manually, when in D it isn't required. The C to D 
> translation goes as follow : FooA => Foo.A instead of Foo.FooA .

That is not the D equivalence of the C code. That is how D 
improves upon C enums. The equivalence and thus the translation 
is to not use a named scope as seen above.

>
> If the goal isn't to follow LLVM's source as closely as 
> possible, I think this is the way to go.

It does follow the LLVM C API source code as closely as possible. 
It just uses a module structure different from LLVM's C API 
header structure for the reasons stated above, which does not 
change how to use the C API (As you should do "import llvm.c.all" 
either way). This is also not a new approach, Derelict (one of 
the major providers for D bindings to C libraries other than 
deimos) has been doing it for a long time.