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