On Friday, 13 May 2022 at 10:37:08 UTC, IGotD- wrote:
> Now we are several months into import C

Actually, it is over a year into it now.

> Import C is an answer to a question we never asked.

Yeah, the fact that ImportC's release mentions dstep's name but says absolutely nothing else about it and my questions about its shortcomings have always gone unanswered tells me there was no serious investigation into the existing options. And since that wasn't done, it seems unlikely there was an actual market analysis either.

I actually have written about these things but apparently neither of my readers have the ear of D lol.

On Friday, 13 May 2022 at 12:57:04 UTC, Adam D Ruppe wrote:
> On Friday, 13 May 2022 at 10:37:08 UTC, IGotD- wrote:
>> Now we are several months into import C
>
> Actually, it is over a year into it now.
>
>> Import C is an answer to a question we never asked.
>
> Yeah, the fact that ImportC's release mentions dstep's name but says absolutely nothing else about it and my questions about its shortcomings have always gone unanswered tells me there was no serious investigation into the existing options. And since that wasn't done, it seems unlikely there was an actual market analysis either.
>
> I actually have written about these things but apparently neither of my readers have the ear of D lol.

market analysis died at the time of the famous first D poll, but anyway I hope that the importC effort at the end turns out to be a success.

One thing I've not understood is why Walter decided not to integrate warp ... I don't remember a clear motivation of this choice

On Friday, 13 May 2022 at 13:04:24 UTC, Paolo Invernizzi wrote:
> One thing I've not understood is why Walter decided not to integrate warp ... I don't remember a clear motivation of this choice

Using system headers means compatibility with the system preprocessor, which might have strange proprietary quirks.

I don't know how much of a problem that is in practice (the current importC guidelines are to just #define away half the header), but that is the reasoning behind it.

But you can still use the system preprocessor. There's an open PR to just shell out to it. Just this still leaves it less capable than dstep already is due to no work with the defined constants.

This is why I wrote this mixin c proposal in last October. Max has started experimenting with it, so there's hope. (And it is just a proposal I wrote up in the middle of a call, it might be horribly useless too, but nobody has actually made an argument yet. Seems the only way to get D leadership attention is to troll comments on Hacker News.)

On Friday, 13 May 2022 at 12:57:04 UTC, Adam D Ruppe wrote:
> On Friday, 13 May 2022 at 10:37:08 UTC, IGotD- wrote:
>> Now we are several months into import C
>
> Actually, it is over a year into it now.
>
>> Import C is an answer to a question we never asked.
>

For me ImportC is *the* killer feature. Currently at work we simply change 1 file from *.c to *.cc fix a few compile-errors and done, this is why C++ became what it is, if D had this from day-1 then I think it would have been a huge success, I can only hope dlang added this feature in time to still succeed, many other languages are starting to catch up.

I have zero interest in adding custom build steps in exotic build systems to generate bindings, nor is it possible to generate static bindings because all other teams update their *.h files daily and we need to be able to use the new features without manual steps.

Now, if you argue that custom build steps is no big thing, then why is CTFE so awesome? No custom build steps, that's why!

On Friday, 13 May 2022 at 13:30:56 UTC, Daniel N wrote:
>
> I have zero interest in adding custom build steps in exotic build systems to generate bindings, nor is it possible to generate static bindings because all other teams update their *.h files daily and we need to be able to use the new features without manual steps.
>

... but import C require a custom build step today to remove all preprocessor text from the .h file. You must have zero interest in import C in that case.

On Fri, May 13, 2022 at 04:18:41PM +0000, IGotD- via Digitalmars-d wrote:
> On Friday, 13 May 2022 at 13:30:56 UTC, Daniel N wrote:
> > 
> > I have zero interest in adding custom build steps in exotic build systems to generate bindings, nor is it possible to generate static bindings because all other teams update their *.h files daily and we need to be able to use the new features without manual steps.
> > 
> 
> ... but import C require a custom build step today to remove all preprocessor text from the .h file. You must have zero interest in import C in that case.

This is why I said, ImportC must be able to preprocess the imported .h file, otherwise it does not add much value to what we already have (not enough to justify its existence anyway).


T

-- 
Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. -- G. Steele

On Fri, May 13, 2022 at 01:12:38PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Friday, 13 May 2022 at 13:04:24 UTC, Paolo Invernizzi wrote:
> > One thing I've not understood is why Walter decided not to integrate warp ... I don't remember a clear motivation of this choice
> 
> Using system headers means compatibility with the system preprocessor, which might have strange proprietary quirks.
> 
> I don't know how much of a problem that is in practice (the current importC guidelines are to just #define away half the header), but that is the reasoning behind it.
> 
> But you can still use the system preprocessor. There's an open PR to just shell out to it. Just this still leaves it less capable than dstep already is due to no work with the defined constants.
[...]

Walter's PR has been merged. So the latest dmd should be able to preprocess .h files automatically now.

As for #define'd manifest constants, wouldn't it just be a matter of adding a separate pass over the .h file to extract #define's that look like they can be transformed into enum constants?  Shouldn't be *that* hard to do, in theory anyway.


T

-- 
Questions are the beginning of intelligence, but the fear of God is the beginning of wisdom.

On Friday, 13 May 2022 at 16:18:41 UTC, IGotD- wrote:
> On Friday, 13 May 2022 at 13:30:56 UTC, Daniel N wrote:
>>
>> I have zero interest in adding custom build steps in exotic build systems to generate bindings, nor is it possible to generate static bindings because all other teams update their *.h files daily and we need to be able to use the new features without manual steps.
>>
>
> ... but import C require a custom build step today to remove all preprocessor text from the .h file. You must have zero interest in import C in that case.

It's work in progress, it will work in the future.

On Friday, 13 May 2022 at 17:27:01 UTC, H. S. Teoh wrote:
>
> As for #define'd manifest constants, wouldn't it just be a matter of adding a separate pass over the .h file to extract #define's that look like they can be transformed into enum constants?  Shouldn't be *that* hard to do, in theory anyway.
>

There must be a similar way as with C compilers (the -D command line option) to inject defines. The D compiler must add this so that import C constants can be defined at the command line otherwise we have that extra custom build step again.