Does D have too many features?

[Alex Rønne Petersen]

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