Thank you for the explanation. It's a bit clearer to me, now.

But what is missing is a compelling use case for it?

On Sunday, 15 May 2022 at 20:08:32 UTC, Andrea Fontana wrote:
> For example this one https://github.com/nayuki/QR-Code-generator/tree/master/c works fine with the follow glue code:

Hah, that is a library (one of the many) I ported to D.

https://github.com/adamdruppe/arsd/blob/master/qrcode.d

It took me about half an hour to do the full conversion by hand and put a basic D api and test on top of it.

Porting C to D is actually a pretty fast process...

On 5/15/2022 4:50 PM, forkit wrote:
> But the PR was submitted with a Trivial tag, suggesting the person submitting that PR did not anticipate the long, windy road ahead (which others did).

Jeez, it was joke!

   -- Captain Obvious

On Monday, 16 May 2022 at 01:05:33 UTC, Walter Bright wrote:
> But what is missing is a compelling use case for it?

It is the only way I've seen that would let you ACTUALLY use full C APIs.

Take a look at some of these macros a quick grep through my system include directory:

pqStubs.h:#define PQcmdTuples (pqStubs->PQcmdTuplesPtr)

curses.h:#define getcurx(win)           (NCURSES_OK_ADDR(win) ? (win)->_curx : ERR)

time.h:# define timerisset(tvp) ((tvp)->tv_sec || (tvp)->tv_usec)


You can convert many of these from C to D with some string manipulations. replace("->", ".") and wrap it in a template function and you will go a long way. (This is what dstep does, and it actually works about 95% of the time.)

But what about this one?

/* Evaluate to actual length of the `sockaddr_un' structure.  */
# define SUN_LEN(ptr) ((size_t) (((struct sockaddr_un *) 0)->sun_path)        \
                      + strlen ((ptr)->sun_path))



The casts get more and more complicated. To convert this starts to require a C parser to convert that code back to D on an ast level... and the C parser is exactly what ImportC is, and D's facility for parsing a string and converting it to a D ast is what `mixin` does.


So combining them thus becomes MixinC.



There's one in this directory I saw before but I don't remember where it is, that has something like

#define item child.item

And you'd use it in C like:

yourstruct.item


So it is basically an `alias this` style forwarder done as a C macro. This is extremely difficult to express in any kind of D conversion, and dpp's approach is very likely to mangle code since it lacks semantic awareness.

MixinC bypasses this - it lets it continue be expressed in C, but it is limited to a single string literal, so it doesn't allow the preprocess to destroy unrelated D code. It is the exact same logic as `mixin` being hygienic as it is, just using C strings instead of D strings.

In some of these cases, you can express the macro in D directly as:

auto SUN_LEN(T)(T ptr) {
 return mixinC(`((size_t) (((struct sockaddr_un *) 0)->sun_path)
                      + strlen ((ptr)->sun_path))`);
}



Or if this isn't done, user code can still:

`size_t s = mixinC("SUN_LEN(my_ptr)");`


Which is syntatically slightly verbose, but that's a cost worth paying to maintain the syntax hygiene.... and it works with *arbitrary macros* (yes, even ones like `#define BEGIN {`, assuming you put the BEGIN and END pieces in the same string, to form a valid AST node).


The C preprocessor is a string macro system. D's mixin is a string to code system. They can work well together!




If your goal is for system headers to Just Work, and it doesn't include some of these macros that are part of the defined API, it is going to fall short. The point of the MixinC concept is to bridge that gap, giving a solution to the preprocessor macro problem.

And besides, notice that, if done right, this can also:

* Enable CTFE to generate C code as well as D code. (You likely could write a C preprocessor in D, run it in CTFE, and mixin the result!)

* Enable deeper introspection into a complete C api, including defined macros and version symbols, allowing custom expressions of those to be used in D.



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) - but making all this work would really feel like actually unlocking the power of tearing down the barriers between C and D.

ImportC as it is now is just "meh, it'd save me 15 minutes every 6 months".

ImportC as it could be might unlock a whole new world of C/D metaprogramming.

Mr. Bright, TEAR DOWN THIS WALL

On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:
> ...
> ....
> ImportC as it could be might unlock a whole new world of C/D metaprogramming.
>
> Mr. Bright, TEAR DOWN THIS WALL

You do understand what lives on the other side of this wall, don't you?

C!

On Monday, 16 May 2022 at 01:54:58 UTC, forkit wrote:
> On Monday, 16 May 2022 at 01:41:17 UTC, Adam D Ruppe wrote:
>> ...
>> ....
>> ImportC as it could be might unlock a whole new world of C/D metaprogramming.
>>
>> Mr. Bright, TEAR DOWN THIS WALL
>
> You do understand what lives on the other side of this wall, don't you?
>
> C!

C is a bad programming language but equally it's the lingua franca of almost everything useful so it's not really up to us.

Recently when I've been fiddling around with the lowing of IR -> LLVM in SDC, the calls to the C API were written roughly 9 years ago and they are all still passing the tests. If you want that kind of stability you have to be able to talk C. I note that the bindings also still work just fine but that's for a different discussion...

Wanna talk to postgres? You're most likely going to need a C library, otherwise you have nothing to ship.

On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:
>
>
> C is a bad programming language but equally it's the lingua franca of almost everything useful so it's not really up to us.

It's the 'lingua franca' because everyone treats it as such ;-)

It's also a frankish language that has contributed to more invalid memory accesses, invalid type casts, memory leaks, data races, deadlocks, etc... than any other language, ever to exist.

But hey, whatever,... , let's just import more of it

:-(

On 16/05/2022 2:53 PM, forkit wrote:
> On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:
>> C is a bad programming language but equally it's the lingua franca of almost everything useful so it's not really up to us.
> 
> It's the 'lingua franca' because everyone treats it as such ;-)
> 
> It's also a frankish language that has contributed to more invalid memory accesses, invalid type casts, memory leaks, data races, deadlocks, etc... than any other language, ever to exist.
> 
> But hey, whatever,... , let's just import more of it
> 
> :-(

Max is correct. It doesn't matter what we want. It is the language that other languages communicate through primarily.

If you want to do anything on Windows you must work with C and COM. So we must support both of them as best as we can. You can't realistically talk to the kernel to replicate this behavior.

If we want D running on proprietary systems that have license restrictions with distribution, we must have a way to create bindings to the C system headers (this is an issue for GDC).

On 5/15/2022 6:41 PM, Adam D Ruppe wrote:
> On Monday, 16 May 2022 at 01:05:33 UTC, Walter Bright wrote:
>> But what is missing is a compelling use case for it?
> 
> It is the only way I've seen that would let you ACTUALLY use full C APIs.

This is replacing C #define's with D constructions, right?

You're right, ImportC does not do that at the moment. However, it's always been the plan for it to gather up all the #define's, and replace the ones that can be replaced with D constructs, and ignore the rest.

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.

I've talked with Atila about how dpp handles it. dpp looks for general patterns, and replaces those with generic D constructs. Atila (always the pragmatist) also programmed in specific replacements for specific #defines that appear in popular .h files. This is indeed an endless game of whack-a-mole, but it works, and it gets the job done.

I intend to leverage Atila's work for ImportC to do the same thing.

(It also may be possible to make these specific patterns something that users can contribute to, so they don't have to wait for the compiler team.)

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

On Monday, 16 May 2022 at 02:53:03 UTC, forkit wrote:
> On Monday, 16 May 2022 at 02:17:50 UTC, max haughton wrote:
>>
>>
>> C is a bad programming language but equally it's the lingua franca of almost everything useful so it's not really up to us.
>
> It's the 'lingua franca' because everyone treats it as such ;-)
>
> It's also a frankish language that has contributed to more invalid memory accesses, invalid type casts, memory leaks, data races, deadlocks, etc... than any other language, ever to exist.
>
> But hey, whatever,... , let's just import more of it
>
> :-(

Unless you have a magic wand or a time machine I don't see how this line of argument has any relevance to the practice of writing software that actually does anything other than making the machine get hot.

One thing I'd also like to note is that once the C has been turned into the D AST you actually can almost get it to emit D code that represents the C