== Quote from Andrei Alexandrescu ([email protected])'s article > dsimcha wrote: > > == 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. > > > Yah. The question is to what extent is that necessary. > Andrei
Too kludgey for me. I'd rather just see ref parameters get fixed and just don't allow taking the address of locals in @safe functions. I'd say that, except in low-level systems programming that would probably not be @safe for other reasons anyhow, there would be very few good if any good reasons to take the address of a local if reference tuples just worked.
