Short list with things to finish for D2

dsimcha dsimcha at yahoo.com
Wed Nov 18 19:12:22 PST 2009


== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> >> dsimcha wrote:
> >>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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.



More information about the Digitalmars-d mailing list