Short list with things to finish for D2

[Pelle Månsson]

Andrei Alexandrescu wrote:
> 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
How about allowing const references to rvalues?