On Mon, May 7, 2012 at 2:10 AM, Jacob Carlborg <doob@me.com> 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.
>
>
That's still correct behavior for C, actually. Using an uninitialized
variable in C results in undefined behavior, so D still complies with C
requirements when it initializes floats to NaN.
I'm guessing there's more to it than that, though, because code that uses
uninitialized floats was probably wrong to begin with.

On 05/07/2012 03:22 AM, Andrew Wiley wrote:
>>
>> I had some problems with floats being default initialized to NaN.
>>
>>
> That's still correct behavior for C, actually. Using an uninitialized
> variable in C results in undefined behavior, so D still complies with C
> requirements when it initializes floats to NaN.

For variables with static storage, C initializes them by default to zero. It's in the spec.

On 4/30/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Personally my gripe with compilation times is that I get very used to having fast build times where I can go through an edit+compile+run cycle really fast, but after a while build times get slower

Also since 2.059 error reporting is *completely* broken. I have to
wait 5 seconds just to get this error message itself to print to the
screen:
http://pastebin.com/y93GEPAf

500 lines of errors even though only the first line is an actual
error. What in the actual fuck are all those other error messages? The
only problem was this line in a main file:
CppGen gen;
and CppGen was undefined because I've missed an import.

And if I remove the only import left (std.range), I get much less
garbage but I still get unrelated errors:
main.d(80): Error: undefined identifier CppGen
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
template std.conv.toImpl does not match any function template
declaration
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
template std.conv.toImpl cannot deduce template function from argument
types !(string)(long)
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
template instance toImpl!(string) errors instantiating template
loader\gcc.d(167): Error: template instance
std.conv.to!(string).to!(long) error instantiating

2.058 error reporting worked fine, I don't know what someone did to screw this up so massively.

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.

I agree that this is a good enough reason in itself.  On top of that, the ANSI C stdlib is a subset of the POSIX API, which is *very* useful to have in druntime.  Phobos (and druntime itself, of course), uses it for everything platform-specific.

-Lars

On 08/05/12 09:56, Andrej Mitrovic wrote:
> On 4/30/12, Andrej Mitrovic<andrej.mitrovich@gmail.com>  wrote:
>> Personally my gripe with compilation times is that I get very used to
>> having fast build times where I can go through an edit+compile+run
>> cycle really fast, but after a while build times get slower
>
> Also since 2.059 error reporting is *completely* broken. I have to
> wait 5 seconds just to get this error message itself to print to the
> screen:
> http://pastebin.com/y93GEPAf
>
> 500 lines of errors even though only the first line is an actual
> error. What in the actual fuck are all those other error messages? The
> only problem was this line in a main file:
> CppGen gen;
> and CppGen was undefined because I've missed an import.
>
> And if I remove the only import left (std.range), I get much less
> garbage but I still get unrelated errors:
> main.d(80): Error: undefined identifier CppGen
> D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
> template std.conv.toImpl does not match any function template
> declaration
> D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
> template std.conv.toImpl cannot deduce template function from argument
> types !(string)(long)
> D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error:
> template instance toImpl!(string) errors instantiating template
> loader\gcc.d(167): Error: template instance
> std.conv.to!(string).to!(long) error instantiating
>
> 2.058 error reporting worked fine, I don't know what someone did to
> screw this up so massively.

That bug was fixed in git not long after release. Unfortunately it seems that there are not enough people doing beta testing.

As for why it happened -- previously the compiler used a hack to prevent the flood of error messages (and the hack didn't work properly in the case where errors were gagged, like in is(typeof()) ). Now it does it properly.

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.

On 5/8/12, Don Clugston <dac@nospam.com> wrote:
> That bug was fixed in git not long after release.

I still get it with this version: http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993 Same errors: http://pastebin.com/8uqgskHd

On 5/8/12, foobar <foo@bar.com> wrote:
> a. C++ is *not* fully source compatible with C, especially the latest C99 conflicts with C++ IIRC.

Yeah there's a nice list in the C++ standard, Annex C.1 (C++ and ISO C). PDF: www-d0.fnal.gov/~dladams/cxx_standard.pdf

foobar:

> 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.

For various reasons I have translated many times routines,
functions and other small and medium amounts of C code to D. And
in many cases I have used the C std lib functions to circumvent
bugs or limitations or performance problems of Phobos. In both
cases I have found the C functions quite useful, so moving them
into not built-in stuff is bad for me. The risk of using C
functions by mistake is low enough.

Bye,
bearophile

On Tuesday, 8 May 2012 at 13:57:30 UTC, bearophile wrote:
> in many cases I have used the C std lib functions to circumvent
> bugs or limitations or performance problems of Phobos. In both

I tend to agree with the performance aspect. I just got done with a very challenging class where we solved programming contest style problems ... we got bonus points for the fastest solution (or solutions that could solve extended versions of the problems).

It was extremely useful for me to be able to use the C versions of functions. Especially I/O because it made it significantly faster to do some things. That said, some of the things I was doing I would never advocate for being easy/possible with D's I/O.