== 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? > * 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.
