On Monday, 16 May 2022 at 11:55:57 UTC, jmh530 wrote:
> On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:
>> As https://github.com/dlang/dmd/pull/14121 has been merged, the following #ImportC program can now be compiled and run:
>>
>>   #include <stdio.h>
>>
>>   void main()
>>   {
>>     printf("hello ImportC!\n");
>>   }
>>
>> [snip]
>
> Sorry if this is a dumb question, but when you refer to something as a "ImportC" program, what precisely do you mean? It's a D program that requires importC features to work?

It's just normal C source code compiled with the ImportC compiler.

On Monday, 16 May 2022 at 12:07:04 UTC, Mike Parker wrote:
> On Monday, 16 May 2022 at 11:55:57 UTC, jmh530 wrote:
>> On Saturday, 14 May 2022 at 21:05:09 UTC, Walter Bright wrote:
>>> As https://github.com/dlang/dmd/pull/14121 has been merged, the following #ImportC program can now be compiled and run:
>>>
>>>   #include <stdio.h>
>>>
>>>   void main()
>>>   {
>>>     printf("hello ImportC!\n");
>>>   }
>>>
>>> [snip]
>>
>> Sorry if this is a dumb question, but when you refer to something as a "ImportC" program, what precisely do you mean? It's a D program that requires importC features to work?
>
> It's just normal C source code compiled with the ImportC compiler.

Thanks. I was confused because I thought "void main" was a D thing and not a C thing.

On Monday, 16 May 2022 at 12:28:59 UTC, jmh530 wrote:

> Thanks. I was confused because I thought "void main" was a D thing and not a C thing.

Yeah, it's not part of the C standard. I don't know if ImportC allows it as a compiler extension or if Walter wrote it by mistake.

On Monday, 16 May 2022 at 05:06:02 UTC, Walter Bright wrote:
> But what I'd do is put that use of the macro in a .c file and import it.

This is impractical for the small expressions many of these macros are designed for. You might as well just write C at that point.

On Monday, 16 May 2022 at 03:12:47 UTC, Walter Bright wrote:
> This is replacing C #define's with D constructions, right?

No. It is about not having to. Instead of converting to D (and being forced to fail in certain cases), you just mixinC.

> I'm not going to pretend this can ever be a complete 100% solution, after all:
>
>    #define BEGIN {
>    #define END }
>
> What can one do with that? Phooey.

This is an example I showed *can actually work* in the message you're quoting. Of course, they'd have to be paired in the mixed in block, but it would work once you get a complete ast node assembled.

Very similar to D's

enum string BEGIN = "{";
enum string END = "}";
mixin(BEGIN ~ "stuff" ~ END);


mixin(BEGIN) obviously not going to work, but if you concat the strings to form a complete statement, you have something that can be used.

The C preprocessor is very similar to string replacement and concatenation.

> But I still don't understand - why mixin this stuff?
> Why would someone want to type C code into a D source file?

Why would someone want to use inline assembler? Why would someone want to use CTFE on C? Why would someone want to type __import in a C file?

On Monday, 16 May 2022 at 13:20:32 UTC, Adam D Ruppe wrote:
> On Monday, 16 May 2022 at 05:06:02 UTC, Walter Bright wrote:
>> But what I'd do is put that use of the macro in a .c file and import it.
>
> This is impractical for the small expressions many of these macros are designed for. You might as well just write C at that point.

I feel like Walter asking about use case could also consider his words earlier in the thread:

> I've done many projects that were universally derided as "who needs that" until they got their hands on it. :-)
> 
> I've also done many projects that everybody wanted, until I delivered it. (dscript)
> 
> It's kinda hard to tell these things in advance, especially if they involve a change in the way people are used to doing things."

On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:
> There's still some things ImportC with MixinC would need design work on - the `import` namespace is still a mess (I'll write a blog about this at some point too, it is past bed time right now)

Here's the post about this:

http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces

On Monday, 16 May 2022 at 17:31:26 UTC, Adam D Ruppe wrote:
> On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:
>> There's still some things ImportC with MixinC would need design work on - the `import` namespace is still a mess (I'll write a blog about this at some point too, it is past bed time right now)
>
> Here's the post about this:
>
> http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces

I reported this as a bug back in January: https://issues.dlang.org/show_bug.cgi?id=22674

On Monday, 16 May 2022 at 17:43:14 UTC, Dave P. wrote:
> I reported this as a bug back in January: https://issues.dlang.org/show_bug.cgi?id=22674

Nice. Yeah, I would have been surprised if I was the first person to notice it, since it is frankly pretty obvious (and happens even with hand-written things from time to time, and was a big issue with dpp, so not even new).

I didn't see that bug though maybe I'll edit the post to put in a link. Walter going "WONTFIX" is pretty much expected though, sadly.

On 5/16/2022 2:52 AM, deadalnix wrote:
> I don't understand where this is going at all. At first, I thought that this was able being able to import c (as the name would suggest), which seems super useful, but now it seems to be evolving into a full blow C compiler and I have no idea why I would want that. I already have several on my machine, and they are extremely high quality.

People can and do put the full C language into .h files (for example, functions that are expected to be inlined).