Short list with things to finish for D2

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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.

But then the @safe or @trusted function wouldn't be able to escape pointers to
heap or static data segment memory either, if I understand this proposal correctly.