On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote:
> On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
>>
>> Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.
>
> And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him.

Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough?

On Monday, 11 October 2021 at 01:08:30 UTC, Paul Backus wrote:
> On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote:
>> On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
>>>
>>> Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.
>>
>> And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him.
>
> Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough?

FWIW The code isn't great. Maybe I'll have another crack at it some day but it wasn't very well structured compared to similar efforts I have seen (e.g. https://developers.redhat.com/blog/2020/03/26/static-analysis-in-gcc-10 's implementation)

On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote:
> Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished.

In retrospect, this is a rather crude message, especially from someone who doesn't contribute anything. Apologies.

On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote:
> ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years.

Why have the other approaches fallen short? How does importC address these problems?

On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote:
> On 10/5/2021 10:36 AM, ag0aep6g wrote:
>> it's also true that Walter prioritizes new features instead (ImportC is the latest fad)
>
> ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years. Unfortunately, ImportC is useless if it only half works. It has to work with existing C headers, which is why I'm concentrating on it to get to that point. Lack of ImportC has wasted a *lot* of developer time, making it a high leverage investment of time.
>
> Just think of all the time lost doing manual conversion of .h files, and then doing them again and again as they evolve. Then not one, not two, but *three* different automated programs were developed to try and resolve this (one of which I wrote). Then think of all the projects *not* done because of the barrier of trying to deal with several thousand lines of .h files.
>
> The Diemos project was an effort to crowdsource conversion of .h files to D, but it just was not adequate.
>
> In summary, ImportC is totally worth the effort. I should have done it 15 years ago.

Agreed. I'm eager to try ImportC in it's full glory when it arrives :)

And when it's "complete" it would be cool to integrate it even further. Maybe some stuff could be automated for example or even be done at design time 😍

On Tuesday, 12 October 2021 at 12:55:16 UTC, Adam Ruppe wrote:
> On Sunday, 10 October 2021 at 23:11:56 UTC, Walter Bright wrote:
>> ImportC resolves a long standing serious issue where multiple other substantial attempts at solving it have fallen short over the years.
>
> Why have the other approaches fallen short? How does importC address these problems?

One of D's ecosystem most valuable set of libraries (BindBC formerly Derelict) are exactly that: translation of C headers by hand. Doing it by hand, until now, has been the preffered way to translate C and C++ headers.

On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote:
> Doing it by hand, until now, has been the preffered way to translate C and C++ headers.

Why did dstep fail for them?

How would importC help the bindBC project?

On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote:
> On Sunday, 17 October 2021 at 17:09:40 UTC, Guillaume Piolat wrote:
>> Doing it by hand, until now, has been the preffered way to translate C and C++ headers.
>
> Why did dstep fail for them?
>
> How would importC help the bindBC project?

I think this is actually an issue with process rather than technology.

The ideal way to do bindings, in my opinion, is to rigorous lock in to / check-in a certain header file, then generate the bindings at build time. ImportC might make that less of a hassle but fundamentally I think the abstraction wrong at the moment.