Make DMD emit C++ .h files same as .di files

[Manu]

On Mon, Feb 25, 2019 at 12:25 PM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 2/25/19 2:04 PM, Manu wrote:
> > On Mon, Feb 25, 2019 at 10:10 AM Andrei Alexandrescu via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> On 2/25/19 5:20 AM, Jacob Carlborg wrote:
> >>> On 2019-02-25 02:04, Manu wrote:
> >>>
> >>>> Why wouldn't you do it in the same pass as the .di output?
> >>>
> >>> * Separation of concerns
> >
> > Are we planning to remove .di output?
> >
> >>> * Simplifying the compiler ("simplifying" is not the correct
> >>> description, rather avoid making the compiler more complex)
> >
> > It seems theoretically very simple to me; whatever the .di code looks
> > like, I can imagine a filter for isExternCorCPP() on candidate nodes
> > when walking the AST. Seems like a pretty simple tweak of the existing
> > code... but I haven't looked at it.
> > I suspect 1 line in the AST walk code, and 99% of the job, a big ugly
> > block that emits a C++ declaration instead of the D declaration?
> >
> >> Indeed so. There's also the network effect of tooling. Integrating
> >> within the compiler would be like the proverbial "giving someone a
> >> fish", whereas framing it as a tool that can be the first inspiring many
> >> others is akin to "teaching fishing".
> >
> > That sounds nice, but it's bollocks though; give me dtoh, i'm about
> > 95% less likely to use it. It's easy to add a flag to the command line
> > of our hyper-complex build, but reworking custom tooling into it, not
> > so much.
>
> More like dog's ones, right? :o)
>
> There are indeed arguments going either way. The point is a universe of
> tools can be built based on the compiler as a library, of which only a
> minority should be realistically integrated within the compiler itself.

Right, but in this case, the technology is *already* in the compiler.
I'm not suggesting a large new development, just a filter on the
output of the existing pass with a bit of a re-format. That form would
be so much more readily useful.

> That said, I'd take such work in either form!

Perhaps. But I'd like to strongly encourage a form that's useful to me
as best as I can... otherwise it's just a nice talking point and still
no practical solution.