Does D have too many features?

[Jonathan M Davis]

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