On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote:
> On 5/3/2012 8:13 AM, Don Clugston wrote:
>> Well, they are also used in druntime, in core.stdc.math
>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be
>> growing -- people are adding more things to it.
>
> It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc.
>
> It's there to make converting C code to D code easier.
>

This argument comes up every once in a while even though AFAIK it
is *not* a goal of D and never has been!
D does not and *should not* strive to be source compatible with
C. We already have C++ for that and it is a horrible idea.
D can link with C which allows to use pre-existing C code. we
should *not* encourage converting C code to D code at all. Either
just link the C code or use D idiomatic code.

IMO C headers should be moved to Deimos, and should be clearly
documented that their intended purpose is to _link_ D code with
the C runtime.

On Sunday, May 06, 2012 21:18:38 foobar wrote:
> On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote:
> > On 5/3/2012 8:13 AM, Don Clugston wrote:
> >> Well, they are also used in druntime, in core.stdc.math
> >> BTW I *hate* that module, I don't know why it exists. Even
> >> worse, it seems to be
> >> growing -- people are adding more things to it.
> > 
> > It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc.
> > 
> > It's there to make converting C code to D code easier.
> 
> This argument comes up every once in a while even though AFAIK it
> is *not* a goal of D and never has been!
> D does not and *should not* strive to be source compatible with
> C. We already have C++ for that and it is a horrible idea.
> D can link with C which allows to use pre-existing C code. we
> should *not* encourage converting C code to D code at all. Either
> just link the C code or use D idiomatic code.

Then you misunderstand. One of the tenets that D holds to is that any C/C++ code either compiles as valid D code with identical semantics, or it doesn't compile as D code (there are a few minor exceptions - such as static arrays being passed by value - but not many). This means that we can break compatibility with C/C++ and do our own thing for a lot of stuff but that we can't just redefine what stuff does such that it would silently break code when it's ported from C/C++ to D.

That approach is _very_ different from C++'s approach where valid C code pretty much _always_ compiles identically in C++ (the fact that C++ added keywords being the only exception that I can think of at the moment), but that doesn't mean that we don't care about code portability from C/C++ to D. There's a huge difference between designing a language such that porting code to it from another language isn't error-prone and making the new language source compatibile. D does the former. C++ does the latter.

Being able to port code from C/C++ to D without having to worry about silent breakage _is_ one of D's goals.

- Jonathan M Davis

On 5/6/2012 8:09 AM, deadalnix wrote:
> I may scare people here, but as Deimos is only declaration, I see no problem to
> use a deimos header in druntime.

I do, because it adds another dependency on something not in the main download.

On 07-05-2012 00:06, Jonathan M Davis wrote:
> On Sunday, May 06, 2012 21:18:38 foobar wrote:
>> On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote:
>>> On 5/3/2012 8:13 AM, Don Clugston wrote:
>>>> Well, they are also used in druntime, in core.stdc.math
>>>> BTW I *hate* that module, I don't know why it exists. Even
>>>> worse, it seems to be
>>>> growing -- people are adding more things to it.
>>>
>>> It's there simply because all the Standard C headers should be
>>> represented. It should not get anything that is not in Standard
>>> C. Ditto for all the other stuff in core.stdc.
>>>
>>> It's there to make converting C code to D code easier.
>>
>> This argument comes up every once in a while even though AFAIK it
>> is *not* a goal of D and never has been!
>> D does not and *should not* strive to be source compatible with
>> C. We already have C++ for that and it is a horrible idea.
>> D can link with C which allows to use pre-existing C code. we
>> should *not* encourage converting C code to D code at all. Either
>> just link the C code or use D idiomatic code.
>
> Then you misunderstand. One of the tenets that D holds to is that any C/C++
> code either compiles as valid D code with identical semantics, or it doesn't
> compile as D code (there are a few minor exceptions - such as static arrays
> being passed by value - but not many). This means that we can break
> compatibility with C/C++ and do our own thing for a lot of stuff but that we
> can't just redefine what stuff does such that it would silently break code when
> it's ported from C/C++ to D.

So basically, language design advances on our front have to be hindered by some kind of compatibility that has *very* questionable usefulness. I have never copy/pasted C/C++ code into D. Ever. Even when making bindings, I type declarations out manually to be completely sure I get them right.

This is like when C++ tried to be source compatible with C. In practice, nearly no one just took a C source base and compiled it as C++ and called it a day, because of two reasons: 1) C++ wasn't actually source compatible enough so that this would just be a tiny build system change, 2) there would be zero gain in doing it. I haven't ever copy/pasted C code into C++ either, now that I think about it.

I don't think you're going to see people port their large C source bases to D just for the sake of doing it. I think, rather, you'll see them write bindings because that's the more pragmatic and time-efficient approach.

BTW, if we're so focused on C/C++ source compatibility, what about the unfortunate D1 folks? We seem to largely not care about source compatibility for their code at all. Seems like our priorities are quite skewed.

>
> That approach is _very_ different from C++'s approach where valid C code pretty
> much _always_ compiles identically in C++ (the fact that C++ added keywords
> being the only exception that I can think of at the moment), but that doesn't
> mean that we don't care about code portability from C/C++ to D. There's a huge
> difference between designing a language such that porting code to it from
> another language isn't error-prone and making the new language source
> compatibile. D does the former. C++ does the latter.

http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B

We probably have many of the incompatibilities mentioned there too.

>
> Being able to port code from C/C++ to D without having to worry about silent
> breakage _is_ one of D's goals.
>
> - Jonathan M Davis

-- 
- Alex

On Monday, May 07, 2012 07:48:05 Alex Rønne Petersen wrote:
> On 07-05-2012 00:06, Jonathan M Davis wrote:
> > On Sunday, May 06, 2012 21:18:38 foobar wrote:
> >> On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote:
> >>> On 5/3/2012 8:13 AM, Don Clugston wrote:
> >>>> Well, they are also used in druntime, in core.stdc.math
> >>>> BTW I *hate* that module, I don't know why it exists. Even
> >>>> worse, it seems to be
> >>>> growing -- people are adding more things to it.
> >>> 
> >>> It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc.
> >>> 
> >>> It's there to make converting C code to D code easier.
> >> 
> >> This argument comes up every once in a while even though AFAIK it
> >> is *not* a goal of D and never has been!
> >> D does not and *should not* strive to be source compatible with
> >> C. We already have C++ for that and it is a horrible idea.
> >> D can link with C which allows to use pre-existing C code. we
> >> should *not* encourage converting C code to D code at all. Either
> >> just link the C code or use D idiomatic code.
> > 
> > Then you misunderstand. One of the tenets that D holds to is that any
> > C/C++
> > code either compiles as valid D code with identical semantics, or it
> > doesn't compile as D code (there are a few minor exceptions - such as
> > static arrays being passed by value - but not many). This means that we
> > can break compatibility with C/C++ and do our own thing for a lot of
> > stuff but that we can't just redefine what stuff does such that it would
> > silently break code when it's ported from C/C++ to D.
> 
> So basically, language design advances on our front have to be hindered by some kind of compatibility that has *very* questionable usefulness. I have never copy/pasted C/C++ code into D. Ever. Even when making bindings, I type declarations out manually to be completely sure I get them right.
> 
> This is like when C++ tried to be source compatible with C. In practice, nearly no one just took a C source base and compiled it as C++ and called it a day, because of two reasons: 1) C++ wasn't actually source compatible enough so that this would just be a tiny build system change, 2) there would be zero gain in doing it. I haven't ever copy/pasted C code into C++ either, now that I think about it.
> 
> I don't think you're going to see people port their large C source bases to D just for the sake of doing it. I think, rather, you'll see them write bindings because that's the more pragmatic and time-efficient approach.

We only require source compatibility so far as C/C++ code which compiles as D code needs to have the same semantics as it does in C/C++. This actually causes very few restrictions, because D's syntax differs enough that compiling C/C++ as D code breaks _very_ quickly. But by having that level of compatability, we make it so that porting code from C/C++ (which people _will_ do, even if the majority of D programmers don't) doesn't break silently.

The only place that I'm aware of where this policy has caused some problems is arithmetic and integral promotions. There a few cases where it would be nice to change the semantics for that, but for the most part, the C/C++ semantics are fine, and I'm sure that Walter considers whatever loss we get there to be worth the gain in making it so that C/C++ code ports to D without breaking silently.

I really don't think that this level of compatibility with C/C++ has cost us much. As similar as D's syntax is, it differs in so many small ways, that C/C++ code quickly fails to compile as D code, and so the small level of compatibility that we insist on doesn't affect much.

> BTW, if we're so focused on C/C++ source compatibility, what about the unfortunate D1 folks? We seem to largely not care about source compatibility for their code at all. Seems like our priorities are quite skewed.

D was frozen as D1 when it was so that the folks using D for real work could continue to do so while major breakages continued to occur as the language was expanded and refined (in particular, const was going to be added, which was going to break a _lot_). It was _never_ intended that D2 be source compatible with D1 or that D1 even stick around long term. It was merely a stable branch which was left around in order to let people continue to use the language for real work while the main branch continued to be developed. In the long run, D1 will be pretty much dead, while we'll still have to worry about people porting C/C++ code to D for pretty much forever.

- Jonathan M Davis

On 2012-05-07 07:48, Alex Rønne Petersen wrote:

> So basically, language design advances on our front have to be hindered
> by some kind of compatibility that has *very* questionable usefulness. I
> have never copy/pasted C/C++ code into D. Ever. Even when making
> bindings, I type declarations out manually to be completely sure I get
> them right.

I've created bindings for libclang, I did that by copy-pasting the C code and then some quick search-and-replace. Although this is the only library I manged to create bindings for this easy.

-- 
/Jacob Carlborg

On 07-05-2012 09:07, Jacob Carlborg wrote:
> On 2012-05-07 07:48, Alex Rønne Petersen wrote:
>
>> So basically, language design advances on our front have to be hindered
>> by some kind of compatibility that has *very* questionable usefulness. I
>> have never copy/pasted C/C++ code into D. Ever. Even when making
>> bindings, I type declarations out manually to be completely sure I get
>> them right.
>
> I've created bindings for libclang, I did that by copy-pasting the C
> code and then some quick search-and-replace. Although this is the only
> library I manged to create bindings for this easy.
>

But declarations are very different from actual statements and expressions (I assume you mean declarations?).

-- 
- Alex

On 2012-05-07 08:03, Jonathan M Davis wrote:

> The only place that I'm aware of where this policy has caused some problems is
> arithmetic and integral promotions. There a few cases where it would be nice
> to change the semantics for that, but for the most part, the C/C++ semantics
> are fine, and I'm sure that Walter considers whatever loss we get there to be
> worth the gain in making it so that C/C++ code ports to D without breaking
> silently.

I had some problems with floats being default initialized to NaN.

-- 
/Jacob Carlborg

On 2012-05-07 09:09, Alex Rønne Petersen wrote:

> But declarations are very different from actual statements and
> expressions (I assume you mean declarations?).
>

That's true. Yes, declarations.

-- 
/Jacob Carlborg

On 07-05-2012 09:10, Jacob Carlborg wrote:
> On 2012-05-07 08:03, Jonathan M Davis wrote:
>
>> The only place that I'm aware of where this policy has caused some
>> problems is
>> arithmetic and integral promotions. There a few cases where it would
>> be nice
>> to change the semantics for that, but for the most part, the C/C++
>> semantics
>> are fine, and I'm sure that Walter considers whatever loss we get
>> there to be
>> worth the gain in making it so that C/C++ code ports to D without
>> breaking
>> silently.
>
> I had some problems with floats being default initialized to NaN.
>

I still think floats being initialized to NaN is an atrocity...

-- 
- Alex