llvm-d

[deadalnix]

On Thursday, 28 March 2013 at 09:23:27 UTC, Moritz Maxeiner wrote:
> 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
>

Ho sorry, I missed that. That is still inferior as it doesn't 
introduce its own type now.

>>
>> 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.
>

This is why I used the word translation. A good translation 
doesn't repeat stupidly, but uses idoms of the target language.

>>
>> 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.

It doesn't follow as closely as possible as the way code is 
structured is part of the code. I also don't see the consistency 
between that choice and the enum one.