On Sunday, 17 October 2021 at 17:55:05 UTC, Adam D Ruppe wrote:
> Why did dstep fail for them?

I don't know; never tried it. Not qualified for an opinion there.

I mean we both use stb_vorbis and many other stuff translated by ketmar by hand to (Alice)D ; not everyone is at his level to do it well.


> How would importC help the bindBC project?

I guess for small libraries you would be able to just embed the file instead of creating bindings. I also assume that ImportC would eat pre-declarations but not sure.

On 11.10.21 03:08, 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?

I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.

On Tuesday, 19 October 2021 at 13:35:16 UTC, Timon Gehr wrote:
> On 11.10.21 03:08, Paul Backus wrote:
>> 
>> 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?
>
> I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.

I this specific case, I agree completely. But there is a broader pattern in D of projects getting "stuck" because a specific individual is unable to continue work on them (e.g., std.experimental.allocator and Andrei), and I think it is worth considering whether we can do anything to make future projects robust against this mode of failure.

On 10/19/2021 6:35 AM, Timon Gehr wrote:
> I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.

Timon and I famously disagree over the concept behind @live.

Nevertheless, we do agree that ImportC is more important.

Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.

On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright wrote:
> On 10/19/2021 6:35 AM, Timon Gehr wrote:
>> I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.
>
> Timon and I famously disagree over the concept behind @live.
>
> Nevertheless, we do agree that ImportC is more important.
>
> Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.

Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost  no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor.

On Wednesday, 20 October 2021 at 05:08:51 UTC, max haughton wrote:
> On Wednesday, 20 October 2021 at 01:48:24 UTC, Walter Bright wrote:
>> On 10/19/2021 6:35 AM, Timon Gehr wrote:
>>> [...]
>>
>> Timon and I famously disagree over the concept behind @live.
>>
>> Nevertheless, we do agree that ImportC is more important.
>>
>> Iain and I have decided that changing the build process so that Phobos' zlib code is built with dmd rather than gcc is going to be our goalpost for declaring ImportC ready to use.
>
> Why is compiling zlib a goalpost for *Import*C? Hopefully that doesn't make it "finished, because that goalpost has almost  no effect on the issues actually plaguing C interop at the moment - i.e. the preprocessor.

I interpreted it as "a goalpost", not *the* goal. I hope at least 🍀

ImportC has the potential to be really powerful. But maybe the later steps doesn't have to be made by Walter?

On 10/19/2021 10:08 PM, max haughton wrote:
> Why is compiling zlib a goalpost for *Import*C?

Dogfooding.

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.

ImportC is more important to me then @live,  because I think I will have a very hard time to make @live to work in my project.

I suppose with ImportC, I an use all the meta programming ability with C header file ? (for example find all struct from a header.h and every details at CTFE time)