Short list with things to finish for D2

[Andrei Alexandrescu]

dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>> 3. It was mentioned in this group that if getopt() does not work in
>> SafeD, then SafeD may as well pack and go home. I agree. We need to make
>> it work. Three ideas discussed with Walter:
>> * Allow taking addresses of locals, but in that case switch allocation
>> from stack to heap, just like with delegates. If we only do that in
>> SafeD, behavior will be different than with regular D. In any case, it's
>> an inefficient proposition, particularly for getopt() which actually
>> does not need to escape the addresses - just fills them up.
> 
> IMHO this is a terrible solution.  SafeD should not cause major ripple effects for
> pieces of code that don't want to use it.  I'm all for safe defaults even if
> they're less efficient or less flexible, but if D starts sacrificing performance
> or flexibility for safety **even when the programmer explicitly asks it not to**,
> then it will officially have become a bondage and discipline language.
> 
> Furthermore, as you point out, having the semantics of something vary in subtle
> ways between SafeD and unsafe D is probably a recipe for confusion.
> 
> 
>> * Allow @trusted (and maybe even @safe) functions to receive addresses
>> of locals. Statically check that they never escape an address of a
>> parameter. I think this is very interesting because it enlarges the
>> common ground of D and SafeD.
> 
> This is a great idea if it can be implemented.  Isn't escape analysis a pretty
> hard thing to get right, though, especially when you might not have the source
> code to the function being called?

Escape analysis is difficult when you don't have information about the 
functions you're passing the pointer to. For example:

void fun(int* p) {
     if (condition) gun(p);
}

Now the problem is that fun's escape-or-not behavior depends on flow 
(i.e. condition) and on gun's escaping behavior.

If we use @safe and @trusted to indicate unequivocally "no escape", then 
there is no analysis to be done - the hard part of the analysis has 
already been done manually by the user.

>> * Figure out a way to reconcile "ref" with variadics. This is the actual
>> reason why getopt chose to traffic in addresses, and fixing it is the
>> logical choice and my personal favorite.
> 
> This should be done eventually regardless of what happens with taking addresses of
> locals, though I'm not sure it still makes the short list if we solve the
> addresses of locals thing some other way.

I agree.


Andrei