[dmd-beta] dmd 1.074 and 2.059 beta 5

[Walter Bright]

On 4/10/2012 5:03 PM, David Nadlinger wrote:
> On 10 Apr 2012, at 19:09, Walter Bright wrote:
>> Includes fixes for all […]
>
> I'll leave you with the last word on this, but I'm still not quite happy with 
> the idea that the result of 7868 [1] is to just accept that an expression 
> silently yields a different result if it is somehow evaluated from a static if 
> condition. The (semi-)regression took me quite some time to track down due to 
> its elusiveness and you some hours to make sense of, and I'm afraid that it 
> will hit other users as well (who probably have no idea about how to debug the 
> frontend).
>
> I am not quite sure about the best way to fix this particular problem – from 
> trying to figure out a way to get the Thrift code working with current Git 
> master it seems that DMD more or less no longer allows adding something to a 
> type based on its current members. It is clear that the semantics of this must 
> be carefully defined, but it is useful for certain »declarative« kinds of 
> meta-programming (especially due to the lack of something like ADL allowing 
> you to »associate« code with a type in another way), it worked in previous DMD 
> releases, and now fails in confusing ways. Maybe we finally need to sit down 
> and formalize our forward reference model (perhaps along the lines of the 
> proposal that came up some time ago – was it by Don? –, for doing semantic 
> analysis one layer of conditionals at a time).
>
> The underlying problem is really that as a developer doing 
> metaprogramming-heavy stuff, you have no idea what actually is supposed to 
> work, and after you found out the hard way by testing what DMD accepts, you 
> still don't know whether it will continue to work in future releases. And this 
> is a much bigger problem than e.g. breaking standard library changes, because 
> you can easily work around the latter.
>

I mostly agree with you, and apologize for the trouble it caused you. The fact 
that it worked at all before was a fluke, caused by incomplete checking by the 
compiler, and that incomplete checking caused numerous other problems.

Allowing forward references in general is a very tricky problem in the situation 
of circular definitions. The strategy that dmd originally followed was to do 
things in lexical order, and dang the consequences. The more advanced strategy 
dmd has been migrating to is to allow circular references as long as there is 
enough information about the partially analyzed type to break the cycle. For 
example, sometimes only the size of a struct is required. Therefore, dmd 
requires only that the members of the struct that contribute to its size are 
analyzed - the other members need not be.

In your case, you had a static if turning on and adding members by checking a 
condition that must check all the members. This cannot possibly work. I spent a 
lot of type trying to figure out a way that the cycle could be legitimately 
broken, but could not.