Ref local variables?

Ben Davis entheh at cantab.net
Tue Jan 10 17:06:21 PST 2012


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);

Here are the alternatives I'm aware of:

- Pointers. I'm using these for now, but it means extra & and * 
operators sometimes, it makes 'ref' less tempting where it IS allowed 
since it's not consistent, and I got the impression that pointers are 
only encouraged when interfacing with C code, so I was surprised to find 
I needed them here. (Am I wrong about this last part?)

- 'with' - doesn't work because of the function call, and also because 
it would only support one tile at once, whereas I sometimes have a few. 
For example I might define 'below=map[(y+1)*w+x]' at the same time, and 
then I can write "if (below.id==CLEAR) {below=tile; tile.id=CLEAR;}".

- Class instead of struct - I don't want to do this since the array is 
quite big and the struct pretty small, and that would be a lot of extra 
overhead.

- Some kind of solution involving 'pretend to be a reference' types with 
difficult-to-read implmenetations and optimisation caveats, not worth 
the fuss compared to using pointers.

Incidentally, this code is already supported:
   int x,y; getValues(x,y);
   void getValues(ref int x, ref int y) ...
Yet it's not clear that x and y are passed by reference - whereas the 
currently unsupported case with local variables doesn't suffer from that 
readability issue, and indeed "below=tile" is much more readable than 
"map[(y+1)*w+x]=map[y*w+x]".

I'd also expect it's trivial in terms of code generation, as parameters 
and local variables are very similar.

So it strikes me as a no-brainer :)

Thanks,

Ben :)


More information about the Digitalmars-d mailing list