On Monday, 29 January 2024 at 06:21:00 UTC, Walter Bright wrote:
> On 1/28/2024 8:11 PM, Lance Bachmeier wrote:
>> On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright wrote:
>> 
>>> It's fair to consider the result. ImportC elicited more or less no interest from anybody. I expected that. Over time, though, its detractors who have tried it have found it to be a game-changing time saver. ImportC is a huge win for D.
>> 
>> I wouldn't say "no interest". This is [what I said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak@forum.dlang.org):
>
> Thanks for reminding me! My mind is like a sieve.
>
>
>>> This will be incredible. I have a lot of use cases for it. In particular on Windows where linking to DLLs is not fun.
>> 
>> It turns out I was a bit too optimistic. The number of dependencies for the typical C project is huge, including things like glib, so avoiding them isn't usually possible. I also underestimated the widespread use of compiler extensions (thankfully this doesn't seem to be much of a problem any longer for ImportC).
>
> I, too, underestimated the pervasive (and usually quite unnecessary) use of bizarro extensions in the C header files. The majority of the problems with ImportC were(are) these extensions.

Surely you of all people would know that? I was one of the first people (that I'm aware of at least) to build and play with ImportC (i.e. slightly prior to it being announced) and it immediately blew up (even after preprocessing) on some GNU headers -- the trend wasn't hard to see.

>> What has worked surprisingly well is converting C headers to D and then using traits to create dynamic bindings at compile time. So while it is not what I originally thought it would be, it's been a win for me in a different way.
>
> You and Adam Wilson! An unanticipated use, for sure.

So what dstep has been doing for years? The value of ImportC is in importing c, i.e. thats the thing that the others can't do. Even then I think the lack of tools for doing it on the fly as part of a build with (say) dub does reveal that the demand is not as great as some think. The language is better with it, obviously, but I'm genuinely not sure if the strategic investment has paid off i.e. it's still in large viewed as a toy / solution for yesterday's problem industrially at least (I think we *switched* to using it for some bits and pieces recently it must be said but it didn't enable anything new).

That and the binding generation is probably not as good as what you can do with DStep because it works with a higher level and frankly much more modern AST from a real C compiler i.e. more info to play with, and info that hasn't potentially been through a bunch of D semantic passes - which does mean that you can potentially do ExportD, in fairness.

On 1/29/2024 5:59 PM, max haughton wrote:
> Surely you of all people would know that? I was one of the first people (that I'm aware of at least) to build and play with ImportC (i.e. slightly prior to it being announced) and it immediately blew up (even after preprocessing) on some GNU headers -- the trend wasn't hard to see.

My priority was compiling Standard C, not C extensions. I assumed that the gnu C headers would at least try to stick with Standard C for the Standard C header files. Oops!

To add more complication, the different Posix versions had dramatically different Standard C header files, using different extensions.

>>> What has worked surprisingly well is converting C headers to D and then using traits to create dynamic bindings at compile time. So while it is not what I originally thought it would be, it's been a win for me in a different way.
>>
>> You and Adam Wilson! An unanticipated use, for sure.
> 
> So what dstep has been doing for years?

As has htod that I wrote, and dpp that Atila wrote.

> The value of ImportC is in importing c, i.e. thats the thing that the others can't do. Even then I think the lack of tools for doing it on the fly as part of a build with (say) dub does reveal that the demand is not as great as some think. The language is better with it, obviously, but I'm genuinely not sure if the strategic investment has paid off i.e. it's still in large viewed as a toy / solution for yesterday's problem industrially at least (I think we *switched* to using it for some bits and pieces recently it must be said but it didn't enable anything new).
> 
> That and the binding generation is probably not as good as what you can do with DStep because it works with a higher level and frankly much more modern AST from a real C compiler i.e. more info to play with, and info that hasn't potentially been through a bunch of D semantic passes - which does mean that you can potentially do ExportD, in fairness.

ImportC is a real C compiler. It doesn't need D to compile, link, and run C programs. It isn't, however, a clone of gcc, clang, or msvc.

The .di code generation happens before semantic analysis, not after.

What info to play with is it missing?

Bottom line - if Dstep works for your purposes, great! Use it!

On 1/29/2024 5:45 PM, max haughton wrote:
> Well the syntax is cleaner but has the potential to be ambiguous both with .d files and the usual <> vs "" stuff.

Right. Putting .c and .d files with the same name in the same directory is not going to work well. The fix is easy and permanent - rename the .d or the .c file.

On 1/29/2024 5:59 PM, max haughton wrote:
> I was one of the first people (that I'm aware of at least) to build and play with ImportC (i.e. slightly prior to it being announced) and it immediately blew up (even after preprocessing) on some GNU headers -- the trend wasn't hard to see.

Yes, you were very helpful it providing excellent bug reports in the early daze of ImportC. Thank you!

On Tuesday, 30 January 2024 at 01:59:47 UTC, max haughton wrote:

> So what dstep has been doing for years?

Not only that, but it does work well for that purpose, and it's baked into the compiler.

> The value of ImportC is in importing c, i.e. thats the thing that the others can't do.

It works well for C code without a ton of dependencies. It can also be used to compile C functions that aren't exported from a library, or to modify parts of a C library without having to maintain your own fork.

On 1/29/2024 8:02 PM, bachmeier wrote:
> Not only that, but it does work well for that purpose, and it's baked into the compiler.

It's kinda the same thing as Ddoc and unittests. Building things into the compiler is transformative.

Heck, once C acquired an inline assembler, I stopped using MASM. Same thing.

On Tuesday, 30 January 2024 at 04:02:30 UTC, bachmeier wrote:
> On Tuesday, 30 January 2024 at 01:59:47 UTC, max haughton wrote:
>
>> So what dstep has been doing for years?
>
> Not only that, but it does work well for that purpose, and it's baked into the compiler.
>
>> The value of ImportC is in importing c, i.e. thats the thing that the others can't do.
>
> It works well for C code without a ton of dependencies. It can also be used to compile C functions that aren't exported from a library, or to modify parts of a C library without having to maintain your own fork.

I'm just wondering how good it is to perform CTFE on C code ... humm
We are using a custom sql parser, imagine being able to use this [1] instead ... at compile time obviously.

[1] https://github.com/pganalyze/libpg_query

/P

On Tuesday, 30 January 2024 at 00:57:31 UTC, Walter Bright wrote:
> On 1/29/2024 1:34 PM, Dibyendu Majumdar wrote:
>> On Sunday, 28 January 2024 at 17:04:02 UTC, Walter Bright wrote:
>>> On 1/28/2024 3:27 AM, Dibyendu Majumdar wrote:
>>>> I don't know if I am right but part of the motivation of import C seems to have been competition - Zig added the ability to compile C. It seems the idea of import C came up after and maybe as a consequence of this.
>>>
>>> I didn't know Zig did that until after I did ImportC.
>> 
>> When did you start on importC?
>> 
>> https://forum.dlang.org/thread/yocvibzernkchgsbcpyb@forum.dlang.org
>
> That post was Dec 3, 2020. The PR for ImportC was May 9, 2021, about 5 months later. When did I start ImportC? I don't recall. I don't recall reading that thread, either, I don't read all the messages, and am generally not interested in detailed comparisons of D with other languages (as it is an endless timesink).
>
> ImportC grew out of my discussions with Atila about dpp.


It doesn't really matter I guess, but its interesting that the discussion I pointed to actually suggested importC and dpp was mentioned, so it seems either you or Atila saw that thread. Maybe a delayed subconscious reaction.

I certainly thought at the time that importC was a reaction to Zig doing it. I recall vaguely you started work on it after that thread.