D has become unbearable and it needs to stop

[Dmytro Katyukha]

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](https://github.com/katyukha/dlibzip). 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](https://github.com/s-ludwig/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.