The forked elephant in the room

max haughton maxhaton at gmail.com
Tue Jan 30 01:59:47 UTC 2024


On Monday, 29 January 2024 at 06:21:00 UTC, Walter Bright wrote:
> On 1/28/2024 8:11 PM, Lance Bachmeier wrote:
>> On Sunday, 28 January 2024 at 05:29:54 UTC, Walter Bright 
>> wrote:
>> 
>>> It's fair to consider the result. ImportC elicited more or 
>>> less no interest from anybody. I expected that. Over time, 
>>> though, its detractors who have tried it have found it to be 
>>> a game-changing time saver. ImportC is a huge win for D.
>> 
>> I wouldn't say "no interest". This is [what I 
>> said](https://forum.dlang.org/post/apozoxpxalpdqiysoqak@forum.dlang.org):
>
> Thanks for reminding me! My mind is like a sieve.
>
>
>>> This will be incredible. I have a lot of use cases for it. In 
>>> particular on Windows where linking to DLLs is not fun.
>> 
>> It turns out I was a bit too optimistic. The number of 
>> dependencies for the typical C project is huge, including 
>> things like glib, so avoiding them isn't usually possible. I 
>> also underestimated the widespread use of compiler extensions 
>> (thankfully this doesn't seem to be much of a problem any 
>> longer for ImportC).
>
> I, too, underestimated the pervasive (and usually quite 
> unnecessary) use of bizarro extensions in the C header files. 
> The majority of the problems with ImportC were(are) these 
> extensions.

Surely you of all people would know that? I was one of the first 
people (that I'm aware of at least) to build and play with 
ImportC (i.e. slightly prior to it being announced) and it 
immediately blew up (even after preprocessing) on some GNU 
headers -- the trend wasn't hard to see.

>> What has worked surprisingly well is converting C headers to D 
>> and then using traits to create dynamic bindings at compile 
>> time. So while it is not what I originally thought it would 
>> be, it's been a win for me in a different way.
>
> You and Adam Wilson! An unanticipated use, for sure.

So what dstep has been doing for years? The value of ImportC is 
in importing c, i.e. thats the thing that the others can't do. 
Even then I think the lack of tools for doing it on the fly as 
part of a build with (say) dub does reveal that the demand is not 
as great as some think. The language is better with it, 
obviously, but I'm genuinely not sure if the strategic investment 
has paid off i.e. it's still in large viewed as a toy / solution 
for yesterday's problem industrially at least (I think we 
*switched* to using it for some bits and pieces recently it must 
be said but it didn't enable anything new).

That and the binding generation is probably not as good as what 
you can do with DStep because it works with a higher level and 
frankly much more modern AST from a real C compiler i.e. more 
info to play with, and info that hasn't potentially been through 
a bunch of D semantic passes - which does mean that you can 
potentially do ExportD, in fairness.





More information about the Digitalmars-d mailing list