On Tuesday, 11 May 2021 at 16:57:15 UTC, IGotD- wrote:
> On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
>> https://github.com/dlang/dmd/pull/12507
>>
>> If you could add a C compiler to dmd with 3000 lines of code, so C code could be imported directly? I would!
>
> I'd say no to this.
>
> Why?
>
> Adding a C compiler into the D compiler will increase the maintenance work load and open up for new interesting bugs. This is the last D needs. Also there are several areas where D needs to improve (memory management) and add this split personally is a distraction.
>
> I also find this a bit strange coming from a person that thinks making GC pointers an own type would increase the complexity of the compiler, then suddenly wants to add a complete C compiler into the D compiler.
>
> Also the question raises what will be supported and what will not. There are a lot of header files out there that are a mix between C and C++. Adding importing C++ is difficult and the scope what is supported must be limited. This means that a lot of header files will not work directly. C++11 and beyond with templates, just forget it.
>
> I understand that importC would greatly make FFI easier but I think this is easier said than done. It is definitely not worth making the D compiler into a Frankensteins monster. I would go the conversion tool (that converts C header files to D files) route in order to decouple a foreign language to the D language.

Read the change log, there are no plans for importing C++ files. C (without the preprocessor nonsense) is a very simple programming language. There are huge number of C libraries out there. The ability to simply import them and "Just work" will be a huge boost to adoption rate when it comes the d language.

-Alex

On Tuesday, 11 May 2021 at 18:37:22 UTC, 12345swordy wrote:
>
> Read the change log, there are no plans for importing C++ files. C (without the preprocessor nonsense) is a very simple programming language. There are huge number of C libraries out there. The ability to simply import them and "Just work" will be a huge boost to adoption rate when it comes the d language.
>
> -Alex

Without the preprocessor many header files will not work. C is general littered with #ifdef. Commonplace is the #ifdef __cplusplus and without the preprocessor the C++ will collide with the C part.

The importC that will "just work", will not be the reality. It's not worth it in my opinion.

On Tuesday, 11 May 2021 at 18:46:26 UTC, IGotD- wrote:
> On Tuesday, 11 May 2021 at 18:37:22 UTC, 12345swordy wrote:
>>
>> Read the change log, there are no plans for importing C++ files. C (without the preprocessor nonsense) is a very simple programming language. There are huge number of C libraries out there. The ability to simply import them and "Just work" will be a huge boost to adoption rate when it comes the d language.
>>
>> -Alex
>
> Without the preprocessor many header files will not work. C is general littered with #ifdef. Commonplace is the #ifdef __cplusplus and without the preprocessor the C++ will collide with the C part.
>
> The importC that will "just work", will not be the reality. It's not worth it in my opinion.

That why in the changelog (Which you didn't read apparently) suggest that you use the gcc '-e' option in your build set up, before you compile it with dmd.

-Alex

On 5/11/2021 6:42 AM, jmh530 wrote:
> Have you tried to mix ImportC with the -betterC flag?
> 
> I wonder what the error looks like if you ImportC a C main function but then also have a betterC D file with a main function.

-betterC is for D code, not C code, and will not affect ImportC.

On 5/11/2021 5:09 AM, Dibyendu Majumdar wrote:
> On Tuesday, 11 May 2021 at 04:16:30 UTC, Walter Bright wrote:
>> On 5/10/2021 3:57 AM, Dibyendu Majumdar wrote:
>>> This seems like a good step forward. I would recommend adding an in-built C  pre-processor.
> 
>> Fortunately, we do have a C preprocessor:
>>
>> https://github.com/DigitalMars/dmpp
> 
> I assume that this will be added as an in-built feature - i.e. not require invoking via another process?


All options for dealing with the preprocessor problem will be on the table after ImportC is finished.

On 5/11/2021 6:37 AM, jmh530 wrote:
> Am I right that Walter basically just moved the warp codebase from the Facebook archive to the Digital Mars one and renamed it dmpp (with maybe some tweaks)?

Not exactly. It was developed in parallel with the Warp repository, for the simple reason that I did not have push rights on Facebook repositories. There are likely some small differences, but I don't know what they are.

Note that it's Boost licensed, so this is not a problem.

Should probably put dmpp on dub.

On 5/11/2021 9:57 AM, IGotD- wrote:
> Adding a C compiler into the D compiler will increase the maintenance work load and open up for new interesting bugs.

True enough. But *any* method of automatically importing/translating C code will have the same problem.


> I also find this a bit strange coming from a person that thinks making GC pointers an own type would increase the complexity of the compiler, then suddenly wants to add a complete C compiler into the D compiler.

ImportC is designed to be a "bag on the side" of dmd specifically to reduce complexity.


> Also the question raises what will be supported and what will not. There are a lot of header files out there that are a mix between C and C++. Adding importing C++ is difficult and the scope what is supported must be limited. This means that a lot of header files will not work directly. C++11 and beyond with templates, just forget it.

I can answer that question: no support for C++!


> I understand that importC would greatly make FFI easier but I think this is easier said than done. It is definitely not worth making the D compiler into a Frankensteins monster. I would go the conversion tool (that converts C header files to D files) route in order to decouple a foreign language to the D language.

ImportC essentially does convert C files to D files, as its output is a D AST. The only way to make any C to D converter is to compile C to an AST, then convert the AST to D. If libclang was used, the exact same thing happens, except libclang hands you a C AST. We (as dpp does) still have to convert the AST.

Attempting to convert C to D using a text macro processor or string matching or some such is doomed to a terrible fate.

On Tuesday, 11 May 2021 at 20:01:18 UTC, Walter Bright wrote:
> On 5/11/2021 6:37 AM, jmh530 wrote:
>> Am I right that Walter basically just moved the warp codebase from the Facebook archive to the Digital Mars one and renamed it dmpp (with maybe some tweaks)?
>
> Not exactly. It was developed in parallel with the Warp repository, for the simple reason that I did not have push rights on Facebook repositories. There are likely some small differences, but I don't know what they are.
>
> Note that it's Boost licensed, so this is not a problem.
>
> Should probably put dmpp on dub.

Thanks!

On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/12507
>
> If you could add a C compiler to dmd with 3000 lines of code, so C code could be imported directly? I would!

I'm gonna say something you don't like. I know everyone (including myself) hates such kind of posts. I'm sorry in advance, I simply don't have an idea how to make you realize that the current way of the language evolution leads to nowhere. Of course, it's your project and not my business. No one owes anyone anything, but if you continue to spread resources on something other than fixing what you already have, I doubt dlang will get more popularity. Nobody wants to invest time/money to build their project based on a broken foundation. Look at the language. It's not consistent. It's just a bunch of features coupled together, part of them don't even work as designed. "shared", "scope", properties, even the initialization of associative arrays aren't finished (and this is just the tip of the iceberg). I've been following these forums for years, trying dlang again and again. Many question threads end with advent of Jonathan M Davis (I really appreciate it) stating a fact that "sadly, it's not implemented/fixed yet". Look at changelogs of dmd. Bugfixes, deprecations and virtually no language improvements/fixes. There are many issues in existing functionality and nobody cares to do something with it. Of course it's much more entertaining to play with integration of a C compiler, rather than do a hard work of trying to eliminate broken/unfinished things. Is there a roadmap with planned features/fixes/improvements for each milestone? You don't plan features/improvements for upcoming releases? It's been many years of stagnation, maybe it's time to finally start working on getting a solid core language?
I know, I know... Who am I to criticize you, right? I've done nothing and you've created a valuable project. I just hope you won't bury the fruit of your many years of hard work and I sincerely wish you a good luck!