An interesting consequence of safety requirements

[Andrei Alexandrescu]

Chad J wrote:
> Andrei Alexandrescu wrote:
[snip]
>> So get ready to use static a lot more ;o).
>>
>>
>> Andrei
> 
> This looks to me like it implicates ref parameters in general.

Yah, and more precisely: ref parameters that you plan to take the 
address of.

It all holds water: if you take a pointer parameter in SafeD, you know 
for sure it's dynamically-allocated because the caller could not have 
taken the address of a stack variable.

[snip]
> Perhaps any ref parameter that has its address taken is marked as being
> unable to accept local variables as arguments.  Additionally, it should
> also not accept a parent function's ref parameters as arguments, since
> those could be local to someone else.  Then if you rewrite member
> functions as static versions with ref parameters as the zeroth arg, they
>  will benefit from the analysis as well.
> 
> Maybe this is too complicated.  If not, hope it helps.

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