The original idea was to have an RDBMS support in phobos:
https://forum.dlang.org/post/ml76cf$c32$1@digitalmars.com
https://github.com/dlang/phobos/pull/3398

On Tue, 2021-06-01 at 08:19 +0000, Kagamin via Digitalmars-d wrote:
> The original idea was to have an RDBMS support in phobos: https://forum.dlang.org/post/ml76cf$c32$1@digitalmars.com https://github.com/dlang/phobos/pull/3398

Ooof. It is clear there was no proper discussion about it and that makes me really sad. I want to be clear that it is not about the importance of having ODBC wrappers in D ecosystem and rather choosing to have it on the standard library.

      I don't see why this should go into Phobos. A Dub package
      should be more than good enough, at least until that planned
      proposal for a standard high-level API materializes. Even then, a
      well-publicized Dub might be more appropriate, given all the
      issues we ran into with std.net.curl. Consider this to be just
      about the most formal veto I can extend.

   Agree, please do not add another c lib dependency to phobos. This
   should be a dub package.

Those guys were literally ignored.

The worst part of this attitude is that Walter didn't read the comments and enabled auto merge tag even if CyberShadow alerted him before merge.

Staff should take care of its community instead of saying "because I want to".

-- 
Sincerely,
Luís Ferreira @ lsferreira.net

On Monday, 31 May 2021 at 17:02:08 UTC, Luís Ferreira wrote:
>
> I see `etc.c.*` headers pretty useless in the standard library. The phylosophy of most of the standard libraries are: provide what "every programmer" might reasonably require when building a large collection of software and provide relatively easy-to-code facilities.
>
> Moving this to the runtime library is totally not a solution to this problem, in my point of view. By definition, a runtime library shouldn't have bindings to a random library that a few people uses.
>

It wasn't moved to the runtime library, it needlessly existed in both places.  One of them had to go.

On Sat, 2021-06-05 at 07:22 +0000, Iain Buclaw via Digitalmars-d wrote:
> On Monday, 31 May 2021 at 17:02:08 UTC, Luís Ferreira wrote:
> > 
> > I see `etc.c.*` headers pretty useless in the standard library. The phylosophy of most of the standard libraries are: provide what "every programmer" might reasonably require when building a large collection of software and provide relatively easy-to-code facilities.
> > 
> > Moving this to the runtime library is totally not a solution to this problem, in my point of view. By definition, a runtime library shouldn't have bindings to a random library that a few people uses.
> > 
> 
> It wasn't moved to the runtime library, it needlessly existed in both places.  One of them had to go.

Ok, sure, thats worse but moving forward is not deleting one of them, IMHO. AFAIK, libodbc is something external, even on windows, so why druntime is still dependent on such bindings?

-- 
Sincerely,
Luís Ferreira @ lsferreira.net

On Sat, 2021-06-05 at 21:14 +0000, Iain Buclaw via Digitalmars-d wrote:
> On Saturday, 5 June 2021 at 17:39:34 UTC, Luís Ferreira wrote:
> > On Sat, 2021-06-05 at 07:22 +0000, Iain Buclaw via Digitalmars-d wrote:
> > > On Monday, 31 May 2021 at 17:02:08 UTC, Luís Ferreira wrote:
> > > > [...]
> > > 
> > > It wasn't moved to the runtime library, it needlessly existed in both places.  One of them had to go.
> > 
> > Ok, sure, thats worse but moving forward is not deleting one of them, IMHO. AFAIK, libodbc is something external, even on windows, so why druntime is still dependent on such bindings?
> 
> Because it is is part of the mingw runtime, and the contributor to `core.sys.windows` translated all headers verbatim.

Oh ok, it makes more sense now, although, I assume it was a mistake.

To be honest, it should be more clear what bindings are valid on the druntime. Logically, bindings for the kernel headers and libc are accepted, but extensions like libodbc should be discussed previously and I think there's no specification for those type of additions.

-- 
Sincerely,
Luís Ferreira @ lsferreira.net