== Quote from Andrei Alexandrescu ([email protected])'s article > dsimcha wrote: > > == Quote from Andrei Alexandrescu ([email protected])'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.
