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

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