dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@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.
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.
Unfortunately it's more complicated than that. getopt takes pairs of
strings and pointers. The strings don't necessarily have to be lvalues,
so constraining getopt to only take references is not the right solution.
Andrei
