On Monday, 3 July 2023 at 11:35:41 UTC, GrimMaple wrote:
> On Monday, 3 July 2023 at 03:12:36 UTC, Walter Bright wrote:
> I have some frustrations, too - how can we focus just on bug fixes while implementing new features at the same time?
Who asked for those features in the first place? Eg. who asked for ImportC? Are you even sure those new features are needed?
> I would like to work on the problems you're experiencing, but it would be nice to have a specific list.
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".
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.