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
