> The only thing I'm aware of which explains anything about the compiler outside
> of the compiler's code itself is this page here:
>
> http://prowiki.org/wiki4d/wiki.cgi?DMDSourceGuide
>
> - Jonathan M Davis

Alright, It seems as if my knowledge is too limited to somehow contribute to a solution.^^

> Basically, someone needs to implement it and then talk Walter into accepting
> it. That'll be easier for someone like Kenji, who's already a major
> contributor, but in theory, anyone can do it. It's just that there's a high
> risk that the pull request would languish for a while. And it would probably
> need to be implemented with a name other than auto ref in order to avoid the
> aforementioned problems, and having to agree on that could cause further
> delay.

I am currently working in the required part of the compiler, but I need help and other opinions.
So far I've tried both: an implementation for auto ref and ref const.

 -> auto ref:
auto ref for non-template functions. In this case (as you had suggested it once) temporary variables are created for rvalues. Thus the behavior of auto ref would be different for template and non-template functions. But I do not see how that would be problematic.

 -> ref const:
const ref creates for rvalues a temporary variable that is then passed to the function. Advantage: It is like C++. Disadvantage: it could break code and you get always a const parameter.

As I said, I've tried both ways before. But I like to hear other opinions which of both would be more preferred.
And I would be glad about any kind of help (looking on my code etc.).
Maybe we could convince Walter and Andrei with a finished implementation.
I hope that no one like to have a new syntax for this kind of thing because then we will discuss another year...

On Monday, March 25, 2013 20:43:29 Namespace wrote:
> > Basically, someone needs to implement it and then talk Walter
> > into accepting
> > it. That'll be easier for someone like Kenji, who's already a
> > major
> > contributor, but in theory, anyone can do it. It's just that
> > there's a high
> > risk that the pull request would languish for a while. And it
> > would probably
> > need to be implemented with a name other than auto ref in order
> > to avoid the
> > aforementioned problems, and having to agree on that could
> > cause further
> > delay.
> 
> I am currently working in the required part of the compiler, but
> I need help and other opinions.
> So far I've tried both: an implementation for auto ref and ref
> const.
> 
> -> auto ref:
> auto ref for non-template functions. In this case (as you had
> suggested it once) temporary variables are created for rvalues.
> Thus the behavior of auto ref would be different for template and
> non-template functions. But I do not see how that would be
> problematic.

Because the number of instantiations of the template could grow exponentially as the number of auto ref parameters grows. Being able to use the trick with the temporary with templated functions could really help reduce template bloat when the current meaning of auto ref is not necessary, but that means coming up with a new attribute rather than reusing auto ref with non-templated functions.

> -> ref const:
> const ref creates for rvalues a temporary variable that is then
> passed to the function. Advantage: It is like C++. Disadvantage:
> it could break code and you get always a const parameter.

Andrei is flat out against this. I wouldn't expect that te over happen.

> As I said, I've tried both ways before. But I like to hear other
> opinions which of both would be more preferred.
> And I would be glad about any kind of help (looking on my code
> etc.).
> Maybe we could convince Walter and Andrei with a finished
> implementation.
> I hope that no one like to have a new syntax for this kind of
> thing because then we will discuss another year...

We pretty much need a new attribute. IIRC, Kenji had a suggestion for what it would be, but I don't remember what it was now. I'd have to go digging through the archives to find it.

- Jonathan M Davis

> Because the number of instantiations of the template could grow exponentially
> as the number of auto ref parameters grows. Being able to use the trick with
> the temporary with templated functions could really help reduce template bloat
> when the current meaning of auto ref is not necessary, but that means coming
> up with a new attribute rather than reusing auto ref with non-templated
> functions.
I use the "trick" with the temporary. But why introduce rather a new attribute?
I thought the real reason why auto ref was first introduced was to solve the rvalue ref problem. Now we could do it. So what's wrong with auto ref for non-
template functions?
I'm afraid that the introducing of a new attribute means to spend a lot of time. Is that really needed? :/ Or am I wrong?

> Andrei is flat out against this. I wouldn't expect that te over happen.
Good to know.

> We pretty much need a new attribute. IIRC, Kenji had a suggestion for what it
> would be, but I don't remember what it was now. I'd have to go digging through
> the archives to find it.
>
> - Jonathan M Davis

I haven't heard of it.
Would be very nice if you could do it and post the link. :)

On Monday, March 25, 2013 23:35:06 Namespace wrote:
> > Because the number of instantiations of the template could grow
> > exponentially
> > as the number of auto ref parameters grows. Being able to use
> > the trick with
> > the temporary with templated functions could really help reduce
> > template bloat
> > when the current meaning of auto ref is not necessary, but that
> > means coming
> > up with a new attribute rather than reusing auto ref with
> > non-templated
> > functions.
> 
> I use the "trick" with the temporary. But why introduce rather a
> new attribute?
> I thought the real reason why auto ref was first introduced was
> to solve the rvalue ref problem. Now we could do it. So what's
> wrong with auto ref for non-
> template functions?
> I'm afraid that the introducing of a new attribute means to spend
> a lot of time. Is that really needed? :/ Or am I wrong?

The problem is that we need the temporary trick with templated functions as well as non-templated functions. auto ref on templated functions as it stands is great for creating parameters that retaining all of the attributes on a type - including refness - but it causes template bloat, which in the case that auto ref was originally intended to solve is completely unnecessary. The temporary trick will work just fine for that, but you can't use auto ref for that on templated functions, because we'd lose out on what it currently does, which is needed for forwarding arguments (much as it was accidental that we got that ability). So, in order to have the temporary trick with templated functions, we need a new attribute. That being the caes, there's no point in implementing auto ref for non-templated functions, as they should just use the same attribute as would be used with template functions.

> I haven't heard of it.
> Would be very nice if you could do it and post the link. :)

I can try, but the search of my e-mail client sucks, so it's always a pain for me to find anything in old posts.

- Jonathan M Davis

I appreciate your efforts and look forward to the link. :)
But I never heard anything about that. How long has it been since that was suggested?

But that's honestly sad to hear. I thought I would contribute to the solution of this problem. Then we'll have to wait and continue to hope.

Forgot to ask:
Wouldn't it be better to publish this decision?
Many still believe the nonsense (like me) that 'auto ref' is still the solution.

On Tuesday, March 26, 2013 00:52:56 Namespace wrote:
> Forgot to ask:
> Wouldn't it be better to publish this decision?
> Many still believe the nonsense (like me) that 'auto ref' is
> still the solution.

An official decision would mean that Walter had been involved in it, and that hasn't happened. IIRC, Andrei said something positive about the temporary approach when it was brought up, but AFAIK, no official decision has been made. It's just that it became clear when discussing it that if we wanted to go with the temporary trick (which looks like the best solution), it really should apply to both templated and non-templated functions and that auto ref needs to retain its current meaning for templated functions, which then means that we need a new attribute. I suppose that we could always create a DIP for it though.

- Jonathan M Davis

You make me curious about this new attribute. Maybe I could then help to implement this along with its task.
I do not think anyone else has the time to do it.
I hope that you will find the link.

I wonder, if someone has already thought about "immutable ref". I can not imagine that many use it, so it wouldn't break (much) code.