I think that would introduce a big potential for bugs. Can't give you an example, but I have a hunch :-)
I think alias is better, since ref doesn't change its target and thus need not be evaluated at run-time. In fact, I think alias should work for any sort of expression. In this case one of D's mottos will be "Too big? Alias it!". On Wed, Jan 11, 2012 at 8:16 AM, Robert Jacques <[email protected]> wrote: > On Tue, 10 Jan 2012 21:55:53 -0600, Nick Sabalausky <[email protected]> wrote: > >> "Ben Davis" <[email protected]> wrote in message >> news:[email protected]... >>> >>> Hi, >>> >>> Please excuse the cross-post with D.learn. People have been helpful there >>> with workarounds, but I'm bringing it here in the hope that we can >>> discuss >>> a language enhancement. >>> >>> So - could support for 'ref' local variables be added, or is there a >>> reason not to? I want to write something like: >>> >>> MapTile[] map; // It's a struct >>> >>> ref MapTile tile=map[y*w+x]; >>> tile.id=something; >>> tile.isWall=true; >>> someFunctionThatTakesRefMapTile(tile); >>> >> >> I *really* want the ability to do that sort of thing, although I think it >> should be an alias rather than a ref variable: >> >> MapTile[] map; // It's a struct >> >> alias map[y*w+x] tile; >> tile.id=something; >> tile.isWall=true; >> someFunctionThatTakesRefMapTile(tile); > > > Would making pointers implicitly convert to ref parameters suffice? i.e. > make > > void foo(ref int x) { x++; } > > int x = 5; > auto y = &x; > foo(y); > > valid D code? -- Bye, Gor Gyolchanyan.
