An interesting consequence of safety requirements

[Brad Roberts]

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