llvm-d

[Moritz Maxeiner]

On Thursday, 28 March 2013 at 17:30:24 UTC, deadalnix wrote:
> 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.

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.

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

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.

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

The way the code (in C) is structured is preserved in the D 
modules by grouping and documentation tags. The C header file 
structure itself is lost, yes, but not the logical structure it 
represent. As such I don't see any vital information being lost 
compared to translating the C headers as D modules.

> I also don't see the consistency between that choice and the 
> enum one.

It is only consistent under the directive "Follow the original C 
API code as closely as possible while minimizing the amount of 
work needed to maintain the result", not in a general sense, but 
consider this:

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

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.