static this sucks, we should deprecate it

Steven Schveighoffer schveiguy at yahoo.com
Thu May 28 09:27:27 PDT 2009


On Thu, 28 May 2009 12:13:01 -0400, Denis Koroskin <2korden at gmail.com>  
wrote:

> On Thu, 28 May 2009 20:00:43 +0400, BCS <none at anon.com> wrote:
>
>> Hello Denis,
>>
>>> On Thu, 28 May 2009 19:44:42 +0400, BCS <none at 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



More information about the Digitalmars-d mailing list