Short list with things to finish for D2

[Andrei Alexandrescu]

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