December 28, 2012
On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
> Namespace:
>
>> How likely is it that "auto ref" will implemented in this release?
>
> Walter wants to release 2.061 "soon". So maybe that's for the successive (unstable?) version of the compiler.
>
> Bye,
> bearophile

As long as it is implemented soon, I'm so satisfied. But an official statement that it will be implemented soon, would be nice.
This feature is really very important and useful.
December 28, 2012
On Friday, 28 December 2012 at 12:47:03 UTC, Namespace wrote:
> On Friday, 28 December 2012 at 12:28:01 UTC, bearophile wrote:
>> Namespace:
>>
>>> How likely is it that "auto ref" will implemented in this release?
>>
>> Walter wants to release 2.061 "soon". So maybe that's for the successive (unstable?) version of the compiler.
>>
>> Bye,
>> bearophile
>
> As long as it is implemented soon, I'm so satisfied. But an official statement that it will be implemented soon, would be nice.
> This feature is really very important and useful.

+1
December 28, 2012
I wrote a workaround for me: I implement it in Romulus. So for these functions:

[code]
void foo(auto ref const Foo f) {
	// do something with f
}

const(int[42]) bar(auto ref const Foo a, auto ref const Foo b) pure nothrow {
	// do something with a and b
}

const(int[42]) quatz(auto ref const Foo a, auto ref const Foo b, auto ref const Foo c) pure nothrow {
	// do something with a and b
}
[/code]

Romulus generates (if they aren't template functions):

[code]
void foo( const Foo f){
	 return foo(f);
}

void foo(ref const Foo f) {
	// do something with f
}

const(int[42]) bar(ref const Foo a, const Foo b)) pure nothrow{
	 return bar(a,b);
}

const(int[42]) bar(const Foo a, ref const Foo b)) pure nothrow{
	 return bar(a,b);
}

const(int[42]) bar( const Foo a,  const Foo b) pure nothrow{
	 return bar(a,b);
}

const(int[42]) bar(ref const Foo a, ref const Foo b) pure nothrow {
	// do something with a and b
}

const(int[42]) quatz(ref const Foo a, const Foo b, const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(const Foo a, ref const Foo b, const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(const Foo a, const Foo b, ref const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(ref const Foo a, ref const Foo b, const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(const Foo a, ref const Foo b, ref const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(ref const Foo a, const Foo b, ref const Foo c)) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz( const Foo a,  const Foo b,  const Foo c) pure nothrow{
	 return quatz(a,b,c);
}

const(int[42]) quatz(ref const Foo a, ref const Foo b, ref const Foo c) pure nothrow {
	// do something with a and b
}
[/code]

I will push it later on my github account. Maybe someone like it.
December 28, 2012
On Friday, December 28, 2012 13:19:01 Namespace wrote:
> In consideration that Andrei said that the implementation of "auto ref" for none-template functions are relatively easy and that until now only the first beta of 2.061 came out: How likely is it that "auto ref" will implemented in this release? Maybe an official statement would be good.
> 
> Purely out of interest, because only then this release would
> really be useful for me (and maybe even for other).
> But of course I know, that I am completely irrelevant. ;)

2.061 is beta. I think that the chances of it having something like this in it are very close to zero.

- Jonathan M Davis
December 28, 2012
> 2.061 is beta. I think that the chances of it having something like this in it
> are very close to zero.
>
> - Jonathan M Davis

You know how to give a suffering hope. :D
December 28, 2012
On Friday, December 28, 2012 22:21:09 Namespace wrote:
> > 2.061 is beta. I think that the chances of it having something
> > like this in it
> > are very close to zero.
> > 
> > - Jonathan M Davis
> 
> You know how to give a suffering hope. :D

LOL. Yeah, well. It's not like I'm going to lie about it.

I'd love to see this fixed as well, but I can't change reality, and I have lots of other stuff that I need to do (much of which is Phobos-related) and not enough time to do it, so I'm not going to spend the time figuring out enough about the compiler to implement it myself. And the reality of the matter is that even if someone implemented it right now, it's unlikely that it would end up in the next release of the compiler, because it's now in beta. The chances aren't necessarily zero, but they're pretty low, and since no one shows any signs of implementing it right now AFAIK, that pretty much puts the chances at zero.

- Jonathan M Davis
December 28, 2012
Spontaneous question: why was the behavior altered from lvalue to rvalue if there is still no replacement with "auto ref" and so a lot of code becomes invalid?
I know of course that the change was necessary, but as long as there is no fix I don't understand such ruthless change.
It meant no offense, I'm just curious.
December 29, 2012
On Friday, December 28, 2012 23:29:38 Namespace wrote:
> Spontaneous question: why was the behavior altered from lvalue to
> rvalue if there is still no replacement with "auto ref" and so a
> lot of code becomes invalid?
> I know of course that the change was necessary, but as long as
> there is no fix I don't understand such ruthless change.
> It meant no offense, I'm just curious.

Because the code was invalid to begin with. It was a bug that it was ever allowed. Not fixing it would just encourage people to continue writing incorrect code and thus break even more code later. And it's not like the functions that currently work with ref or const ref are going to later when the auto ref situation is sorted out, since it's almost certain that that will be solved with auto ref and not by changing anything with ref or const ref.

Also, there's the cost in confusion caused by allowing foo(S(5)) but not foo(bar()). So, in some ways, allowing the broken behavior actually causes more problems than fixing it does.

- Jonathan M Davis
December 29, 2012
So when it will be fixed I will be able to write:

void foo(auto ref Vector3 v);

and it will pass copies or references depending on the situation?
December 29, 2012
On Saturday, 29 December 2012 at 18:43:37 UTC, Minas Mina wrote:
> So when it will be fixed I will be able to write:
>
> void foo(auto ref Vector3 v);
>
> and it will pass copies or references depending on the situation?

Yes. The compiler generates the function for the specific situation.
So you have in the worst case 2^n permutations of the function.
See also my implementation in Remus/Romulus. This generates actually _all_ permutations.