January 11, 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 :)
January 11, 2012
"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
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
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
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
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
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
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
"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
"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