DIP74 - where is at?

[Timon Gehr via Digitalmars-d]

On 10/11/2015 10:35 PM, Andrei Alexandrescu wrote:
> ...
>
> 1. You say that DIP25 is a failure. More so, you demand that is admitted
> without evidence.

FWIW, DIP25 is insufficiently formal and/or incorrect.
I have been able to find those holes in the implementation pretty 
quickly (I'll also put them to bugzilla):


---

enum N=100;
ref int[N] foo(return ref int[N] s)@safe{ return s; }
int[N]* bar(return ref int[N] s)@safe{ return &foo(s); }
ref int[N] baz()@safe{ int[N] s; return *bar(s); }

// for illustration:
void bang(ref int[N] x)@safe{ x[]=0x25BAD; }
void main()@safe{ bang(baz()); }

---

enum N=100;
ref int[N] fun(ref int[N] x)@safe{
     ref int[N] bar(){ return x; }
     return bar();
}
ref int[N] hun()@safe{
     int[N] k;
     return fun(k);
}

// for illustration:
void bang(ref int[N] x)@safe{ x[]=0x25BAD; }
void main()@safe{ bang(hun); }

---

ref int foo()@safe{
     struct S{
         int x;
         ref int bar()return{ return x; }
     }
     return S().bar();
}

// fun fact: paste it twice into a D file to get an ICE :-)

---

ref int foo()@safe{
     int x;
     struct S{
         ref int bar(){ return x; }
     }
     return S().bar();
}
// (the DIP quite explicitly allows this,
// as x lives longer than 'this'.)

---

Basically every technique I have tried to use for escaping references to 
locals and non-return parameters directly after reading the DIP has been 
fruitful. This seems like a pretty obvious failure to achieve "with the 
proposed rules, it is impossible in safe code to have ref refer to a 
destroyed object" to me.
Had the DIP explicitly mentioned all necessary rules in more detail, 
there would probably be fewer cases like this. Its true complexity would 
then also be more apparent. (Be it low or high, but at least it would be 
a leveled playing ground.)

> What I see is a feature that solves one problem, and
> solves it well: annotating a function that returns a reference to its
> argument.

When you say "well", what do you mean?

My personal definition of "well" for such cases is that all the 
contextual information needed to type check an expression can be encoded 
into the type signature of a function. (Unfortunately, D violates this 
rule quite often.) I don't think there is a syntax-free way of fixing 
the holes which satisfies this, as the return attribute inherently 
throws away e.g. the information about which nested scope a reference 
returned after being accessed through a context pointer refers to.


> The syntactic cost is low,

I have noticed you tend to attach a large weight to "syntactic cost". 
How to evaluate syntactic cost of a feature? I think concepts that exist 
but have no syntax have a larger cost.

> and the impact on safety is positive.
> Walter and I think it is the simplest solution of all considered.

I'm not entirely sure. It has the lowest amount of syntax though.