D as an extension language for C

Walter Bright newshound2 at digitalmars.com
Wed May 17 03:30:02 UTC 2023


On 5/16/2023 12:48 AM, Patrick Schluter wrote:
> On Monday, 15 May 2023 at 20:19:05 UTC, IGotD- wrote:
>> On Sunday, 14 May 2023 at 23:56:55 UTC, Walter Bright wrote:
>>>
>>> There are a number of C features which do not translate into D. But with 
>>> ImportC I can make them work seamlessly.
>>
>> What are the C features that cannot be expressed in D?
> 
> VLA's and flexible arrays.

Some more things:

1. struct tags and non-tag names co-existing in the same scope

2. enum member names get "promoted" to the surrounding scope, losing their enum-ness

3. bit fields (since fixed by adding bitfields to D!)

4. C's everything-in-one-global-namespace issue

5. default initialization isn't always zero in D

6. different rules for `const` (ImportC admittedly fakes it)


If you look at the frontend source code, the semantic routines have lots of "if 
it's C do this instead".

Of course, "cannot" is an absolute word. There are always ways to make something 
work, but the result may be just too ugly or otherwise unpalatable. With 
ImportC, we just let C be C instead of trying to bash it into D code.


More information about the Digitalmars-d mailing list