On Thu, 5 Nov 2009, Andrei Alexandrescu wrote: > Thanks. It's a reenactment of a discussion that Bartosz, Walter and I have had > a few times: should the compiler collect the so-called "function summaries" > during compilation and augment the signatures with additional properties, or > should we require the user to annotate the signatures themselves? > > Collecting function summaries is a classic in many program analysis, but is > difficult to scale and to combine with separate compilation (usually > interesting summaries require collecting info about all functions and then > doing a sort of fixed point iteration). > > So far dmd never relies on collecting a function summary, but that may change > in the future. > > > Andrei
The key difference for me has always been that user specified traits (be they annotations, keywords, whatever) is that it's defining the intended contract. Anything inferred is useful only so far in that it might allow usage where not explicitly intended. For example, imagine a function declared to take a function pointer for which the function must be pure. That explicitly allows any annotated function to be used (that matches the rest of the signature, obviously), but might also allow the use of any detected pure function. The risk being that the detected as pure function might change at some future date -- since it's signature didn't require enforcement of that purity -- and break the call site. >From what I can see, there's three alternatives: 1) strict policy -- no inference done at all 2) strict policy -- inference allowed to influence optimization, but not change semantics 3) inference allowed at the semantic layer, potentially allowing future issues. I'm personally most in favor of #2. We're currently in the land of #1. Later, Brad
