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