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?

On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar wrote:

>
> I assume that this will be added as an in-built feature - i.e. not require invoking via another process?

> The C code must be run through a preprocessor before it can be processed by ImportC. Incorporating this into your build system is advisable.

https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11

On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
> On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar wrote:
>
>>
>> I assume that this will be added as an in-built feature - i.e. not require invoking via another process?
>
>> The C code must be run through a preprocessor before it can be processed by ImportC. Incorporating this into your build system is advisable.
>
> https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11

Also:
> Some means of incorporating this may be practical. For now, use cpp, warp or spp.

https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor

On Tuesday, 11 May 2021 at 12:51:07 UTC, Mike Parker wrote:
> On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
>> On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar wrote:
>>
>>>
>>> I assume that this will be added as an in-built feature - i.e. not require invoking via another process?
>>
>>> The C code must be run through a preprocessor before it can be processed by ImportC. Incorporating this into your build system is advisable.
>>
>> https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
>
> Also:
>> Some means of incorporating this may be practical. For now, use cpp, warp or spp.
>
> https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor

Or import a single file CPP implementation :-)

On Tuesday, 11 May 2021 at 12:51:07 UTC, Mike Parker wrote:
> On Tuesday, 11 May 2021 at 12:48:59 UTC, Mike Parker wrote:
>> On Tuesday, 11 May 2021 at 12:09:21 UTC, Dibyendu Majumdar wrote:
>>
>>>
>>> I assume that this will be added as an in-built feature - i.e. not require invoking via another process?
>>
>>> The C code must be run through a preprocessor before it can be processed by ImportC. Incorporating this into your build system is advisable.
>>
>> https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#variance-from-iso-c11
>
> Also:
>> Some means of incorporating this may be practical. For now, use cpp, warp or spp.
>
> https://github.com/WalterBright/dmd/blob/ImportC/changelog/ImportC.md#c-preprocessor

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

Your responses don't really address the core of his point, which is whether dmpp - specifically - will be what is incorporated in the future. I assume it is.

On Monday, 10 May 2021 at 02:51:35 UTC, Walter Bright wrote:
> On 5/9/2021 7:22 PM, Brian wrote:
>> As a new user to D, I was legitimately surprised that D didn't already compile C with the very explicit writings about DasBetterC, going so far as to having a -betterC flag. Perhaps that was my mistake in understanding the language. I wonder how many other newcomers also experience that confusion.
>
> Having both ImportC and DasBetterC is definitely a messaging issue.

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.

On Tuesday, 11 May 2021 at 13:37:39 UTC, 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)?

I believe so, yes.

>
> Your responses don't really address the core of his point, which is whether dmpp - specifically - will be what is incorporated in the future. I assume it is.

Well, my first response was intended to show that no preprocessor of any kind was going to be integrated. Then I saw the future direction section after I posted it. So I'll step out and leave it to Walter to answer.

On 5/9/21 8:55 PM, Adam D. Ruppe wrote:
> 2) preprocessor macros are bad and should be kept far away from D code. but since C headers often define them you're thrust into this hell. dpp makes it worse though because of its translation model - it has no semantic awareness of actual need. so it ends up doing silly things like turning import core.sys.linux to import core.sys.1. These tend to be fixed with some ad-hoc #undef at the end of the translated section, or sometimes translating certain macro patterns into superior D patterns, adn enough work toward that will prolly achieve like 95% goodness. but there's still bound to be some case that got missed no matter what.

I had this idea: what if in D code, you can access CPP macros explicitly. Like:

#CMACRO(<macro expression)

Which then you can use by running a specialized c preprocessor on your d code. C macros can only be defined in C header files, and if you choose to accept the above ugliness, then it properly translates that part to what the c preprocessor spits out. If the C preprocessor is not enabled (the default option), the macro call is an error.

This gives you the possibility to use C headers directly, doesn't interfere with normal D code, and also encourages you to find better ways to do the macro-y things if possible to get rid of the ugliness.

Another option is to allow CPP macros with a pragma scope:

pragma(cmacro, on);
pragma(cmacro, off);

Which might hide some of the ugliness, but still is opt-in for using macros.

-Steve

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.

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:
>> [...]
>
> I'd say no to this.
>
> Why?
>
> [...]

C++ support isn't a goal here tho.

And I'm not sure this would add such a big maintenance cost, Walter can do this in his sleep ⚡