On Tuesday, 2 April 2013 at 17:30:33 UTC, kenji hara wrote:
> I think 'scope ref' is better.
> 'in' = 'const scope', then 'in ref' = 'const scope ref'.
>
> bool opEquals(in ref T rhs) const { ... }
>
> Kenji Hara
> 2013/03/30 21:06 "Namespace" <rswhite4@googlemail.com>:
>
>> As far as I studied the code, something like @ref isn't possible, because
>> ref is already a keyword. Except as Pseudo-property. But this is a
>> combination of '@' and 'ref' so that both, '@ref' and '@ ref' would be
>> valid.
>> I still like the idea of '&A'.

As far as I know Jonathan was strict against it, or not?
But that sounds and looks nice and would be very easy to implement.

My try for scope ref/in ref:
https://github.com/Dgame/dmd/tree/in_ref

On Tuesday, 2 April 2013 at 15:08:20 UTC, Namespace wrote:
> On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
>> As far as I studied the code, something like @ref isn't possible, because ref is already a keyword. Except as Pseudo-property. But this is a combination of '@' and 'ref' so that both, '@ref' and '@ ref' would be valid.
>> I still like the idea of '&A'.
>
> I have to disagree with me here.
> Thanks to this thread (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk@forum.dlang.org) I know now that after the '@' can be an unlimited number of white spaces.
> Hence my previous speculation that I would have implemented something wrong is wrong. So is something like '@ref' possible and already implemented, as you can see here: https://github.com/Dgame/dmd/tree/rvalue_property
>
> I think this is probably the end result of my little journey. Any objections?

'@ref' is actually my least favorite choice. Of all presented, my two favorites are

void func(ref& int a) {}

void func(@val ref int a) {}

Hara Kenji's comment about 'scope ref' also raises the issue of just how subtle is the difference between this proposed feature and what 'auto ref' does in templates. Correct me if I'm wrong, but 'ref&' is proposed to have the compiler create a temporary at the call site and pass it as a reference.

ref int func1(ref& int a) { return a; }

// Example:

int func2(ref int b) { return a; }
int x = func2(func1(3));

The above passes because the temporary ref to "3" created for func1 survives the whole expression, I believe. func1 returns the 3 as a ref, which ref should not escape the original expression, but may escape func1 itself. So 'scope ref' cannot be used. 'scope ref' *could* be used for the related "performance ref" issue, wherein the compiler decides whether a ref or value is appropriate knowing full well there's no chance of escaping.

There are actually three ref issues here. The performance ref issue is related to the compiler making automatic choices which have no affect on semantics. The other two issues are related to the Don't Repeat Yourself problem. 'auto ref' is the template solution which actually creates new functions depending on what is passed to it. The alternative solution is what's being proposed here, which I'll call the 'temp ref' solution. Instead of passing values to a custom created function, all rvalues are simply converted to temporary lvalues at the call site, with the caller responsible for tracking the value's scope.

It might seem convenient to use the syntax 'auto ref' to tell a non-templated function to do this, but that syntax has been rejected for reasons I either never understood well enough or I've simply forgotten.

All-in-all, the syntax 'ref &' seems harmless enough to me. As far as getting it to work with templates, the feature is clearly mutually exclusive with 'auto ref', but I'm not sure why any other usage would be a problem.

On Wednesday, 3 April 2013 at 01:19:18 UTC, Zach the Mystic wrote:
> On Tuesday, 2 April 2013 at 15:08:20 UTC, Namespace wrote:
>> On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
>>> As far as I studied the code, something like @ref isn't possible, because ref is already a keyword. Except as Pseudo-property. But this is a combination of '@' and 'ref' so that both, '@ref' and '@ ref' would be valid.
>>> I still like the idea of '&A'.
>>
>> I have to disagree with me here.
>> Thanks to this thread (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk@forum.dlang.org) I know now that after the '@' can be an unlimited number of white spaces.
>> Hence my previous speculation that I would have implemented something wrong is wrong. So is something like '@ref' possible and already implemented, as you can see here: https://github.com/Dgame/dmd/tree/rvalue_property
>>
>> I think this is probably the end result of my little journey. Any objections?
>
> '@ref' is actually my least favorite choice. Of all presented, my two favorites are
>
> void func(ref& int a) {}
>
> void func(@val ref int a) {}
>
> Hara Kenji's comment about 'scope ref' also raises the issue of just how subtle is the difference between this proposed feature and what 'auto ref' does in templates. Correct me if I'm wrong, but 'ref&' is proposed to have the compiler create a temporary at the call site and pass it as a reference.
>
> ref int func1(ref& int a) { return a; }
>
> // Example:
>
> int func2(ref int b) { return a; }
> int x = func2(func1(3));

s/ref int b/ref int a/

> It might seem convenient to use the syntax 'auto ref' to tell a non-templated function to do this, but that syntax has been rejected for reasons I either never understood well enough or I've simply forgotten.
In my first post I link to Jonathan response to this.

> All-in-all, the syntax 'ref &' seems harmless enough to me. As far as getting it to work with templates, the feature is clearly mutually exclusive with 'auto ref', but I'm not sure why any other usage would be a problem.

I like 'ref&' also, but the reaction seemed to imply that it looks not like a temp ref, more like a double ref. So we came back to '@ref'.
And in terms of 'scope ref': scope works currently only for delegates so you could customize the behavior of scope ref quite appropriately. 'scope ref' is my second favorite alternative.
The ranking would be:
1. ref&
2. scope ref / ref in
3. @ref

For all of these a proposal and a finished implementation of mine is ready, you have to choose and to review only. :)

It would interest me which of the suggestions would be rather accepted.
 - scope ref as Kenji suggested
 - Or rather @ref because this is the way that D usually goes when it comes to subsequent expansions.

What do you think?

On Wednesday, 3 April 2013 at 17:48:54 UTC, Namespace wrote:
> It would interest me which of the suggestions would be rather accepted.
>  - scope ref as Kenji suggested
>  - Or rather @ref because this is the way that D usually goes when it comes to subsequent expansions.
>
> What do you think?

I am against introducing new one-symbol meanings, it always looks like a hack. scope ref is much more elegant but I still can't get straight in my mind what this combination does mean from the abstract type system point of view.

On Wednesday, 3 April 2013 at 18:06:36 UTC, Dicebot wrote:
> On Wednesday, 3 April 2013 at 17:48:54 UTC, Namespace wrote:
>> It would interest me which of the suggestions would be rather accepted.
>> - scope ref as Kenji suggested
>> - Or rather @ref because this is the way that D usually goes when it comes to subsequent expansions.
>>
>> What do you think?
>
> I am against introducing new one-symbol meanings, it always looks like a hack. scope ref is much more elegant but I still can't get straight in my mind what this combination does mean from the abstract type system point of view.

So you were against the introduction of ravalue references or do you just have a problem with the syntax?

> I am against introducing new one-symbol meanings, it always looks like a hack. scope ref is much more elegant but I still can't get straight in my mind what this combination does mean from the abstract type system point of view.

Addendum to scope ref: It could mean: "This ref parameter accepts also rvalues​​, because no reference can leave the scope". Therefore it is safe to pass a rvalue by ref.

On Wednesday, 3 April 2013 at 17:48:54 UTC, Namespace wrote:
> It would interest me which of the suggestions would be rather accepted.
>  - scope ref as Kenji suggested
>  - Or rather @ref because this is the way that D usually goes when it comes to subsequent expansions.
>
> What do you think?

I simply can't reconcile the stated intention of 'scope' parameters with this feature. And '@ref' really makes no sense to me, being even less intuitive than 'ref&'. My belief is that this feature carries with it an inherent frustration because the existing syntaxes can't accomodate it, each being just slightyl off the mark, and to add a whole new keyword or '@' storage class seems like not getting too much reward for the convenience the feature provides.

'scope ref': The only existing documentation on scope parameters: http://dlang.org/function.html suggests that references to them simply cannot leave the function they find themselves in. But this is *not* what the temp ref feature is about. Say you have this temp ref function:

ref int func(@temp ref int a) { return a; }

According to the spec, it clearly violates 'scope', but is nonetheless valid and safe, as far as I can tell. The compiler can easily track the scope of a given lvalue at the call site:

static int* x;
static int y;
x = *func(3); // Error: result of func(3) is assumed to be local
x = *func(y); // Pass: address of y is known to be global

This kind of safety checking is not yet implemented, but is suggested in DIP25, http://wiki.dlang.org/DIP25 . I believe it is the right way to go. The locality of the return by reference is assumed to be as local as the reference which is passed into it. So the temp '3' reference would make the result of func(3) yield a local, barring any other information which would allow the compiler to safely assume otherwise. In essence, '@temp ref' can escape its scope safely because the locality of the result is not its responsibility.

As far as the fact that the meaning of 'scope' is not yet set in stone and may change to adapt to new purposes, the question would be whether its current definition is useful enough as is without needing to expand it (rather counter-intuitively, to be honest) to mean something different.

'@ref': I like this less than 'ref&' because it is even less clear what it means than 'ref&' is. The two problems with 'ref&', so far as I understand it, are 1, that it looks like a one-character hack which generally not well-liked in this community, and 2, it could be confused with a double-reference. I personally don't think I'm going to confuse 'ref&' with 'ref *'. At least 'ref&' gives a hint that it has something to do with taking the address of something. '@ref' is nothing more than saying, "Hey, I can take '@' and put it before keyword 'ref'. Look at me!". I'm not for it at all.

If 'ref&' or '@ref' are rejected on the basis of their being one-character hacks, then the search is on for a good '@' word or an existing keyword which does the trick. I wish 'scope' could cover it, but I personally don't see how that keyword as defined covers this feature as proposed. I looked for other existing keywords to do the job, but I didn't find one which met my personal sense of what would work. 'auto ref' would have been a perfect name for it if 'auto ref' hadn't already found great use in templates. All I have, therefore, are '@val' and, given this post, '@temp':

void func(@val ref int a) {}
void func(@temp ref int a) {}

I think '@val' is pretty good. I don't think this feature merits its own keyword, so the '@' is there to stay, but at least '@val' is only four letters long, exactly the same number of characters as 'auto'.

Does anyone else have a better '@ttribute' for this feature, assuming one-char hacks are out of the question?