On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:

Who asked for those features in the first place? Eg. who asked for ImportC? Are you even sure those new features are needed?

This entire thread is a list of problems, yet your only response is "Do it yourself". So I'm not buying this "I would like to work on the problems you're experiencing".

On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

Recently translated miniz (a zlib replacement) from C to D and Dennis' ctod didn't make it through the unbelievable macros, and it was a drag to expand the macros by hand.
I will very probably use ImportC when it can find the preprocessor on Windows, which has been a blocker here. So many codebases have been translated from C to D it can be indeed valuable. Moreover ImportC is also a fast C compiler so it can eventually help build times of D projects by rewriting in C :)

On Monday, 3 July 2023 at 11:50:32 UTC, Guillaume Piolat wrote:

So to help projects in D you should re-write them in C? Huge W for the language, GG. Big confidence boost!

On Monday, 3 July 2023 at 11:56:40 UTC, GrimMaple wrote:

If I can keep part of my stack in C by just not translating them to D then it would be a win, since then you get the breadth of C libs + faster compile time. The pragma(pack) and __align work is needed to get there... it's not lack of confidence not to start a JPEG decoder from scratch, it is way faster to translate.

On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

I didn't ask, but I sure am happy ImportC exists!

--Bastiaan.

On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

Why so many hate for ImportC? I am waiting when it will be ready and supported by LDC, thus i will be able to use some C libraries without pain.

For example, it took too much time to understand how to generate (and then manually process) D definitions for such simple library as libzip. I am waiting when ImportC will be supported by LDC, and then i will be able to use it for example for this wrapper around libzip (https://github.com/katyukha/Zipper).

Also, i want to use D to create some internal service to parse git repositories (few hundreds repos), and for this reason i want to use libgit2 C library. But without ImportC ready, i do not want to even try to manually generate D bindings for for that. I have seen and tried to use libgit2 D bindings, even added there 1 PR. But currently, i see that without ImportC, it will be impossible to maintain such kind of bindings with reasonable (for me) efforts. Especially, taking into account different versions of libgit2.

Thus i think, ImportC is important feature that could significantly boost D ecosystem.

Also, i want to create libpq wrapper for postgresql database similar for python's psycopg (no classes, only ref-counted structs, no integrated orm, just simple and reliable library). But the only thing that stops me to start work on it (except time) is that ImportC is not ready yet (not supported by LDC and has some bugs). I will not even try to start work on such projects without ImportC.

So, please, stop hate ImportC.

In case of LTS, i support that D needs some kind of LTS release, or at least keep backward compatibility as much as reasonably possible. But, i think, that before starting of LTS, at least following features have to be completed (no need to use -preview to enable them):

• DIP1000 support
• ImportC
• Preview In (good to have, but not necessary)
• Something other that is partially ready and may be necessary for D ecosystem.

I think that, things that have to be backported to (or may be forwardported from) LTS release must include:

• regressions
• critical bugfixes
• bugfixes that require reasonable amount of work to backport.
• possibly some deprecation warnings (i think it is good to know that some feature will be removed as early as possible).
• possibly some safe (fully backward-compatible features that require reasonable amount of work to backport).

In case of reasonable amount of work, i mean: why not to backport fix/feature if it could take not more then few hours.

On Monday, 3 July 2023 at 13:59:56 UTC, Dmytro Katyukha wrote:

FYI, I'm cross-compiling and cross-linking targeting Windows from a Mac, using ImportC to handle directly the ffmpeg API, using LDC.

I just love that.

/P

On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:

I'm not using it in D right now, but every compiler I've ever made has had some variant of ImportC. It's a great feature, and I am hype that it's in the language.

On Monday, 3 July 2023 at 13:59:56 UTC, Dmytro Katyukha wrote:

Unrelated, but I plan to make a miniz package with this translation, since it could maybe simplify using zlib. (some of the APIs aren't supported though)
https://github.com/AuburnSounds/gamut/blob/main/source/gamut/codecs/miniz.d

Also translated lz4 (but not lz4hc).