View mode: basic / threaded / horizontal-split · Log in · Help
January 11, 2012
Ref local variables?
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 :)
January 11, 2012
Re: Ref local variables?
"Ben Davis" <entheh@cantab.net> wrote in message 
news:jeinah$2pnj$1@digitalmars.com...
> 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);
January 11, 2012
Re: Ref local variables?
On Tue, 10 Jan 2012 21:55:53 -0600, Nick Sabalausky <a@a.a> wrote:

> "Ben Davis" <entheh@cantab.net> wrote in message
> news:jeinah$2pnj$1@digitalmars.com...
>> 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?
January 11, 2012
Re: Ref local variables?
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 <sandford@jhu.edu> wrote:
> On Tue, 10 Jan 2012 21:55:53 -0600, Nick Sabalausky <a@a.a> wrote:
>
>> "Ben Davis" <entheh@cantab.net> wrote in message
>> news:jeinah$2pnj$1@digitalmars.com...
>>>
>>> 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.
January 11, 2012
Re: Ref local variables?
What about the semantics here?

alias MapTile tile=map[y*w+x];
x++;
tile.id=something;

Personally I'd find 'ref' more intuitive since it doesn't have that 
question. Not that I'd object to alias ALSO being supported.

I'm probably not actually going to change any of those variables in my 
case, so if I had to use alias, I'd just want to be sure that the common 
subexpression elimination can pick it up. (My case is actually 3D fwiw.)

Note that this is already supported (apologies if I've got the syntax 
slightly wrong):

foreach (i, ref tile; map) { ... }

That's a local variable too. It could have instead been defined such 
that "tile" is an alias for "map[i]", but that would be a little strange.

On 11/01/2012 08:18, Gor Gyolchanyan wrote:
> 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<sandford@jhu.edu>  wrote:
>> On Tue, 10 Jan 2012 21:55:53 -0600, Nick Sabalausky<a@a.a>  wrote:
>>
>>> "Ben Davis"<entheh@cantab.net>  wrote in message
>>> news:jeinah$2pnj$1@digitalmars.com...
>>>>
>>>> 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?
>
>
>
January 11, 2012
Re: Ref local variables?
On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <entheh@cantab.net> wrote:

> 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?

This has been requested in the past.  In order to convince Walter, it is  
helpful to examine past failed arguments.  Try a search on the newsgroups  
archive.

You also have to show why it's better to do it via the language than via  
the library.  I think Simen's solution in the D.learn thread is pretty  
compelling.

-Steve
January 11, 2012
Re: Ref local variables?
Am 11.01.2012, 14:27 Uhr, schrieb Steven Schveighoffer  
<schveiguy@yahoo.com>:

> On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <entheh@cantab.net> wrote:
>
>> 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?
>
> This has been requested in the past.  In order to convince Walter, it is  
> helpful to examine past failed arguments.  Try a search on the  
> newsgroups archive.
>
> You also have to show why it's better to do it via the language than via  
> the library.  I think Simen's solution in the D.learn thread is pretty  
> compelling.
>
> -Steve

Sorry, but it sounds plain masochistic to import a module and then  
instantiate a template every time you want quick access to variable in  
non-trivially indexed array. All I want is a pointer to that element, but  
if possible avoid the pointer syntax. Here is another example:

	Row* rt_a = &row_types[n_row_types];
	rt_a.pattern = pattern & MASK_HIGH_BIT;
	foreach (b, ref rt_b; row_types[0 .. n_row_types]) {
		if ((rt_a.pattern & rt_b.pattern) == 0) {
			rt_a.combinations ~= b;
			rt_b.combinations ~= n_row_types;
		}
	}
	++n_row_types;

Every solution proposed so far obfuscates and/or increases lines of code.  
I don't mind templates or alias this, I use them in other situations.  
Especially with the alias syntax (alias row_types[n_row_types] rt_a) I  
have the logical problem, that rt_a is just a macro, not the manifest  
pointer to the requested array slot. If I change n_row_types afterwards,  
rt_a changes. The other issue is that the OP has a more involved indexing  
scheme, that slows down the code if evaluated again and again.

Local ref variables on the other hand (if it doesn't break the language)  
are a way to use pointers without pointer syntax. That precludes any form  
of pointer arithmetics and unsafe operations that are generally connected  
to the idea of pointers on these variables. Especially in @safe code I  
would not want to resort to pointers, but write more in a Java style where  
everything is a reference.

Again, the problem is the lack of a clean, concise syntax to declare  
references to structs (either returned from a function as ref or retrieved  
from an array). Or we just stick to pointers (that I manage to avoid  
everywhere else, but in this case).

- Marco
January 11, 2012
Re: Ref local variables?
On Wed, 11 Jan 2012 15:12:36 -0500, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am 11.01.2012, 14:27 Uhr, schrieb Steven Schveighoffer  
> <schveiguy@yahoo.com>:
>
>> On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <entheh@cantab.net> wrote:
>>
>>> 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?
>>
>> This has been requested in the past.  In order to convince Walter, it  
>> is helpful to examine past failed arguments.  Try a search on the  
>> newsgroups archive.
>>
>> You also have to show why it's better to do it via the language than  
>> via the library.  I think Simen's solution in the D.learn thread is  
>> pretty compelling.
>>
>> -Steve
>
> Sorry, but it sounds plain masochistic to import a module and then  
> instantiate a template every time you want quick access to variable in  
> non-trivially indexed array.

I disagree, this doesn't look that bad:

auto tile = refOf(map[y*w+x]);

If you're saying that importing a module to do this is too much, I think  
you will have an uphill battle convincing Andrei/Walter.

-Steve
January 11, 2012
Re: Ref local variables?
"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message 
news:op.v7xweevveav7ka@localhost.localdomain...
> On Wed, 11 Jan 2012 15:12:36 -0500, Marco Leise <Marco.Leise@gmx.de> 
> wrote:
>
>> Am 11.01.2012, 14:27 Uhr, schrieb Steven Schveighoffer 
>> <schveiguy@yahoo.com>:
>>
>>> On Tue, 10 Jan 2012 20:06:21 -0500, Ben Davis <entheh@cantab.net> wrote:
>>>
>>>> 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?
>>>
>>> This has been requested in the past.  In order to convince Walter, it 
>>> is helpful to examine past failed arguments.  Try a search on the 
>>> newsgroups archive.
>>>
>>> You also have to show why it's better to do it via the language than 
>>> via the library.  I think Simen's solution in the D.learn thread is 
>>> pretty compelling.
>>>
>>> -Steve
>>
>> Sorry, but it sounds plain masochistic to import a module and then 
>> instantiate a template every time you want quick access to variable in 
>> non-trivially indexed array.
>
> I disagree, this doesn't look that bad:
>
> auto tile = refOf(map[y*w+x]);
>
> If you're saying that importing a module to do this is too much, I think 
> you will have an uphill battle convincing Andrei/Walter.
>

It falls squarely into the category of "removing unnecessary restrictions in 
the langauge", which Andrei at least has said he's interested in. We already 
have ref variables: You're just currently limited to only using them as 
params. This is just simply lifting that restriction. Just like how we 
lifted the restriction of imports only being usable at the top-level of the 
AST.

Resorting to a library may allow the same feature, but it's *very* 
unorthogonal and messy, and for no real benefit. (Granted, I've never been a 
fan of obsessing over othogonality, but throwing it away for no benefit is 
no good either.)
January 11, 2012
Re: Ref local variables?
"Ben Davis" <entheh@cantab.net> wrote in message 
news:jejkdm$16un$1@digitalmars.com...
>
> Note that this is already supported (apologies if I've got the syntax 
> slightly wrong):
>
> foreach (i, ref tile; map) { ... }
>
> That's a local variable too. It could have instead been defined such that 
> "tile" is an alias for "map[i]", but that would be a little strange.
>

That's a very good point.

Technically, foreach is implemented such that its body is a function and the 
"i, ref tile" is the parameter list. But I think that's beside the point.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home