Over the years, I've given a fair amount of thought to, and talked about it with various people:

   import "foo.h";

or something similar as a way to interface existing C (or even C++) code to D. On the plus side, I have a C/C++ front end which could be adapted to do this. On the minus,

1. there may be various #define's necessary to compile it that would normally be supplied on the command line to the C compiler

2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char types)

3. rather few .h files seem to be standard compliant C. They always rely on various compiler extensions

4. the license would be the same as for the back end

5. having a C/C++ front end as a "bag on the side" of a D compiler seems like a heavy burden to anyone wanting to write a D compiler, besides being a fairly massive maintenance effort as it would have to be kept up with the latest C/C++ standards and extensions

Essentially, I think it is impractical, and in the worst case scenario, could actually sink D because of the diversion of effort necessary. Instead, any such tool should be a separate tool, designed, built, and maintained separately. Perhaps DMD could call it like it calls the linker.

On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:
> Perhaps DMD could call it like it calls the linker.

But then DMD would have to act as the middle-man between the 3rd party tool and the header files (e.g. it would have to pass custom flags to the tool, there's no question how many flags could exist..). I don't see much benefit to it.

It also doesn't help that `import "foo.h"` does who-knows-what behind the scenes, for example there's the question of which generated D module is actually then imported, and what do the actual D declarations look like? The user has to know, otherwise he can't use the wrapper code just by looking at the foo.h header file.

On Wednesday, 17 July 2013 at 22:52:40 UTC, Walter Bright wrote:
> 4. the license would be the same as for the back end

Why even bother starting this thread?

On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:
> Why even bother starting this thread?

Because the topic comes up now and then.

On Wednesday, 17 July 2013 at 23:10:36 UTC, Walter Bright wrote:
> On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:
>> Why even bother starting this thread?
>
> Because the topic comes up now and then.

I couldn't imagine anyone doing a significant amount of work only to have their work marked with a DigitalMars & Symantec stamp.

On 7/17/13 3:52 PM, Walter Bright wrote:
> Over the years, I've given a fair amount of thought to, and talked about it with various people:
>
>     import "foo.h";
>
> or something similar as a way to interface existing C (or even C++) code to D. On the plus side, I
> have a C/C++ front end which could be adapted to do this. On the minus,
>
> 1. there may be various #define's necessary to compile it that would normally be supplied on the
> command line to the C compiler
>
> 2. there are various behavior switches (see the PR for DMD that wants to set the signed'ness of char
> types)
>
> 3. rather few .h files seem to be standard compliant C. They always rely on various compiler extensions
>
> 4. the license would be the same as for the back end
>
> 5. having a C/C++ front end as a "bag on the side" of a D compiler seems like a heavy burden to
> anyone wanting to write a D compiler, besides being a fairly massive maintenance effort as it would
> have to be kept up with the latest C/C++ standards and extensions
>
> Essentially, I think it is impractical, and in the worst case scenario, could actually sink D
> because of the diversion of effort necessary. Instead, any such tool should be a separate tool,
> designed, built, and maintained separately. Perhaps DMD could call it like it calls the linker.

6. the time cost of parsing/semanticing c/c++ is significantly higher than D, making .h importing dwarf the rest of the cost of the compilation process

7. .h files are roughly static so translating them on each compilation unit is wasteful, generate once as part of the build process and update only as needed.  This is stuff that build processes are good at.

On 7/17/2013 4:18 PM, Andrej Mitrovic wrote:
> On Wednesday, 17 July 2013 at 23:10:36 UTC, Walter Bright wrote:
>> On 7/17/2013 4:01 PM, Andrej Mitrovic wrote:
>>> Why even bother starting this thread?
>>
>> Because the topic comes up now and then.
>
> I couldn't imagine anyone doing a significant amount of work only to have their
> work marked with a DigitalMars & Symantec stamp.

Symantec would not automatically own any derived work, they would only own the original.

As for DM, yes, it'd be necessary to assign copyright to DM. Otherwise, having source files with a dozen different copyrights on various lines of code in it is completely impractical. Tango got into difficulty, for example, because various people owned various copyrights in it, meaning that the license could not be changed as it was hard to reach them all, let alone get any sort of consensus agreement.

These kinds of issues are, of course, why Phobos is Boost licensed.

And lastly, the use of github ensures that contributors get credit for their work regardless of license/copyright issues. It's just one of the things that makes github such a great collaborative tool for us.

I think it would be really cool if D could compile in header files. But also agree the tradeoffs really suck. And if DMD does it as a compiler extension then it is as good as required. If it was done in LDC or GDC I wouldn't consider it a problem at all.

Ultimately an easy to install 3rd party program should be fine. I haven't needed to convert header files for a while so never attempted dstep yet.

On 07/18/2013 12:52 AM, Walter Bright wrote:
> 4. the license would be the same as for the back end

I take it using a different C/C++ frontend (such as clang) is out, at least for
DMD ... ?

> Essentially, I think it is impractical, and in the worst case scenario, could actually sink D because of the diversion of effort necessary. Instead, any such tool should be a separate tool, designed, built, and maintained separately. Perhaps DMD could call it like it calls the linker.

Personally I don't mind whether it's part of the compiler or a separate tool, as long as there is a solution available that makes it easy to link to C/C++ code without having to manually write bindings.  Though I imagine that for optimal performance, some manual work will always be necessary.

On 2013-07-18 00:52, Walter Bright wrote:

> 4. the license would be the same as for the back end

The license of what?

> 5. having a C/C++ front end as a "bag on the side" of a D compiler seems
> like a heavy burden to anyone wanting to write a D compiler, besides
> being a fairly massive maintenance effort as it would have to be kept up
> with the latest C/C++ standards and extensions

Yes, that's why a library like libclang should be used.

-- 
/Jacob Carlborg

On 2013-07-18 01:53, Brad Roberts wrote:

> 6. the time cost of parsing/semanticing c/c++ is significantly higher
> than D, making .h importing dwarf the rest of the cost of the
> compilation process
>
> 7. .h files are roughly static so translating them on each compilation
> unit is wasteful, generate once as part of the build process and update
> only as needed.  This is stuff that build processes are good at.

Yeah, that's true. This year Clang has got support for modules. Basically a better and safe(er) version of percompiled headers.

-- 
/Jacob Carlborg