Does D have too many features?

[deadalnix]

Le 08/05/2012 13:59, foobar a écrit :
> On Sunday, 6 May 2012 at 22:06:32 UTC, Jonathan M Davis wrote:
>>> 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
>
> I have a three main problems with the above:
>
> a. C++ is *not* fully source compatible with C, especially the latest
> C99 conflicts with C++ IIRC.
> b. D isn't either - there are already semantics changes compared to C,
> as you said so yourself, e.g. static arrays, default initialization of
> static floats, etc.
> c. If this is currently a goal of D it really shouldn't be - it prevents
> us from fixing design bugs we inherited from C such as implicit numeric
> coercions.
>
> As others said, the only thing that sort-of makes sense is to copy/paste
> *declarations* and even those are different enough in D that they
> deserve at least a look over to make sure they are correct.
>
> We shouldn't promote this "goal" at all especially given that it isn't
> even guarantied to be 100% correct in all cases.
> Really what we should be promoting is the fact that D is _link_
> compatible with C and allows you to use existing C code _without_
> porting it to D.

I think that goal is misunderstood. It is aimed at human being, not 
compiler.

If one read D code that look like C, it should be able to understand it 
easily. I is not supped to compile with 100% exact semantic.