C compatibility

[Bill Baxter]

On Wed, Jul 15, 2009 at 8:50 AM, BCS<none at anon.com> wrote:
> Hello grauzone,
>
>> BCS wrote:
>>
>>> Reply to Jacob,
>>>
>>>> I've read posts in several threads complaining about the C
>>>> compatibility, the latest was the % operator. Other complains are
>>>> that you can use the C syntax for pointers, arrays and function
>>>> pointers. Also the "Case range statement" thread that complained
>>>> (among other things) about fall through in switch statements.
>>>>
>>>> Why not the drop this C compatibility in general case
>>>>
>>> One thing Walter is adement about is that copy-n-paste C code must
>>> run correctly (i.e the same) in D or not compile. As for the C style
>>> type syntax, I'd be willing to see that go en-total.
>>>
>> But what for?
>> - For headers, you can't include use the C source directly, because
>> there are far too many preprocessor directives. Also, headers consist
>> mostly of declarations, and not function bodies.
>
> granted
>
>> - Normal code you can simply compile in C and link to D. This works
>> perfectly fine. There's no real reason to port it to D. And who ports
>> large portions of code from C to D anyway?
>
> Linking C code can get a bit cludgy when you actually go to use it because
> of type system miss matches (e.g. C's char* vs. D's char[]). Also cross
> language inlining doesn't happen. If it's a small block of code, <~200 LOC,
> I'd consider copying the code and pushing the types thought. If you can
> count on the correct-or-error bit, this is a lot easier.

Also the pain of multi-language debugging and managing a
multi-language build process is sometimes greater than the pain of
just porting the darn thing.  D is still mostly a superset of C, so I
find porting to be kind of semi-mindless fun.  Like solving crossword
puzzles.  There's a little bit of thinking involved but not too much.

--bb