On Thu, 28 May 2009 12:13:01 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Thu, 28 May 2009 20:00:43 +0400, BCS <n...@anon.com> wrote:
Hello Denis,
On Thu, 28 May 2009 19:44:42 +0400, BCS <n...@anon.com> wrote:
Hello Steven,
fails to compile due to the perceived circular dependency, even
though none exists.
IIRC it compiles, but fails as soon as you run it.
-Steve
Which is even worse. Walter stated that "silently generating bad code"
(i.e. code that doesn't work) is a top priority bug.
I wonder why this design flaw isn't fixed for so long...
It's not silent. It fails loudly, reliably and immediately. The only way
it can slip thought is if you don't even TRY to run the exe before you
ship.
Generating code has nothing to do with running it (unless compiler
automatically runs compiled executable before returning 0)
As far as DMD is concerned, is does silently generate a binary that
doesn't work (and yes, you notice it immediately when you run it).
That's *exactly* the same as silently generating bad executable. You run
it and get "Executable is corrupted" message (or something like this).
I don't believe it can be used as an excuse for not fixing this bug.
You are misinterpreting Walter's statements. He wants the compiler not to
generate silent errors. That is, errors which do not show up during a
normal build/test process, mostly because of unexpected changes in the
compiler interpretation of source files (e.g. hijacking). I don't think
he meant that he wants the compiler not to generate code that was
erroneously designed, or could have been erroneously designed, especially
if the result is a deterministically immediate crash. For all practical
purposes, running the executable is a part of the build process. You are
a fool if you ship untested code simply because it compiles. This
argument you are having has nothing to do with the problem at hand.
The reason this hasn't been fixed is because it's not easy to do without
redesigning how D imports work. It's not simply a "bug".
-Steve
