Why can't we make reference variables?

[Tommi]

On Wednesday, 29 August 2012 at 14:17:21 UTC, Era Scarecrow wrote:
>  Then most of my examples change to going into the constructor 
> rather than out, and the global one goes away. But it still 
> doesn't help with the problem of anything stack allocated.
>
>  struct S {
>    //default construtor otherwise then fails to work because of 
> ref? Since
>    //x must be known at compile time so it would be null to 
> start with, or no
>    //default onstructor
>    ref int x;
>    this(ref int r) { x = r;}
>  }
>
>  S func() {
>    int local = 42;
>    S s = S(local);
>    return s;
>  }
>
>  S func(ref int reffed) {
>    S s = S(reffed);
>    return s;
>  }
>
>  S s = func();
>
>  writeln(s.x); //mystery value still!
>
>  {
>    int local = 42;
>    s = func(local);
>    writeln(s.x); //42
>  }
>
>  writeln(s.x); //!?!?
>
>
>  Unless I'm understanding this wrong (And I'm tired right now 
> maybe I missed something), once again the only safe 'reference 
> variable' is from actively being called from a live accessible 
> reference; And anything else is still a ticking timebomb and 
> cannot ever be @safe. Stuff referencing within heaped/class 
> related stuff may suffer fewer problems, but only as long as 
> you rely on the GC and not do any magic involving malloc/free, 
> or maybe a dynamic range.
>
>  Reminds me. The example for the foreach are missing parts.
>
>  int[10] fixed;
>  int[] dynamic;
>  dynamic.length = 10;
>
>  foreach(i; fixed) {
>     //fine, i is a copy
>  }
>
>  foreach(ref i; fixed) {
>      //compile-time error for @safe checking
>      //cannot ensure this is safe otherwise
>  }
>
>  foreach(i; dynamic) {
>     //fine, i is a copy
>  }
>
>  foreach(ref i; dynamic) {
>     //Dynamic/heap allocated, so fine.
>  }
>
>  //from function/ref
>  void func(int[] huh) {
>    foreach(ref i; huh) {
>      //????? safe?
>    }
>  }
>
>  //both legal last I checked.
>  func(fixed);
>  func(dynamic);
>
>
>
>  My god, as I look at this more, reference variables would 
> cripple D so badly C++ wouldn't look half bad afterwards.

I honestly don't know anything about memory safety and what it 
entails. So, I can't comment about any of that stuff. But if you 
say general ref variables can't be implemented in @safe mode, 
then I can just take your word for it. But what I'm saying is 
that ref variables would be a nice feature to have in @system 
code.

My logic is very simple: since we can use pointers in @system 
code, and references are no more unsafe than pointers, then we 
should be able to use references in @system code. You might argue 
that references are little more than syntactic sugar (and a bit 
safer) compared to pointers, but you shouldn't underestimate the 
importance of syntactic sugar especially when you're trying to 
lure in users of C++.