Would like to see ref and out required for function calls

[David Piepgrass]

On Thursday, 13 September 2012 at 15:01:28 UTC, Andrei 
Alexandrescu wrote:
> On 9/13/12 10:53 AM, David Piepgrass wrote:
>>> Walter and I have discussed this for quite a while. We have 
>>> recently
>>> decided to disallow, at least in SafeD, escaping the address 
>>> of a ref
>>> parameter. In the beginning we'll be overly conservative by
>>> disallowing taking the address of a ref altogether. I'll 
>>> write a DIP
>>> on that soon.
>>
>> Err, wouldn't that break a lot of stuff, a lot of which is 
>> actually safe
>> code?
>>
>> void a(ref int x) { b(&x); }
>> void b(int* x) { if(x != null) (*x)++; }
>
> Yes. Disallowing taking the address of a local is conservative 
> and would disallow a number of valid programs.
>
> Arguably, such programs are in poor style anyway. A good 
> program takes pointers only if it needs to keep them around; if 
> all that's needed is to use the parameter transitorily or pass 
> it down, ref is best.

Another common reason to use a pointer (instead of ref) is if 
it's optional (nullable). If the parameter is ref then the caller 
must go to the trouble of creating a variable.

However, this could be solved with a feature like the following:

int* find(string searchString, out int index) { ... }
// _ means "don't care", assuming no variable "_" is defined
void caller() { find("foo", out _); }

In fact this is arguably better for 'out' variables since the 
callee (find) no longer has to check whether 'index' is null 
before assigning it. However this doesn't totally solve the 
problem for 'ref' parameters, since such parameters are both 
output and input parameters and the programmer may want 'null' to 
have some special meaning as an input.

>> Escaping the addresses of stack variables, not just ref 
>> parameters, is a
>> general problem in "safe" D. Do you have any ideas about that?
Btw just a simple illustrative example:
int* unsafe1() { int x = 1; return unsafe2(&x); }
int* unsafe2(int* x) { return x; }
int unsafe3() { int y = 7; *unsafe1() = 8; return y; }
enum gaff = unsafe3(); // ICE, no line number given

> Same thing. By and large safe programs will need to make more 
> use of the garbage collector than others. It's the way things 
> work; stack allocation can be made safer if we add typed 
> regions, but that's a very significant escalation of 
> complication. There is no simple solution to this today.

Same thing meaning that you'd propose disallowing taking the 
address of a stack variable in SafeD? (I guess this would include 
escaping 'this' within a struct.)