December 29, 2012
On Saturday, December 29, 2012 19:43:36 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?

For templated functions, it currently generates either

void foo(ref Vector3 v);

or

void foo(Vector3 v);

depending on whether you pass it an lvalue or an rvalue. The situtation with non-templated functions has not been sorted out yet, but what will probably happen once it has been is that if you declare

void foo(auto ref Vector3 v);

then underneath the hood, you'll only get

void foo(ref Vector3 v);

but when it's passed an rvalue, it will get automatically assigned to a local variable first and then that local variable will leave scope after the function call. So,

foo(bar());

will turn into something like

auto _temp = bar();
foo(_temp);

In either case, the idea is that if you declare a parameter to be auto ref, it will accept both rvalues and lvalues and do so without making unnecessary copies, whereas ref will still specifically require an lvalue. So, you use ref when you want to mutate the original, and you use auto ref when you don't care whether it gets mutated or not but don't want a copy to be made if it doesn't have to be (and you use auto ref const if you want to avoid the copy but guarantee that it doesn't get mutated).

- Jonathan M Davis
December 30, 2012
> 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.

I've played with this a bit today. The code is at https://github.com/jerro/dmd/tree/auto-ref. I know next to nothing about DMD, so it could be all kinds of wrong, but it does at least seem to work.

What do you think should happen in this case:

void foo(auto ref int a){}
void foo(int a){}
...
foo(1);

should this be an error, or should the second overload be called? And what about this:

void foo(auto ref int a){}
void foo(ref int a){}

For this to work, the name mangling for auto ref should be different than for ref, but I'm not sure there's value in making it work.
December 30, 2012
> I've played with this a bit today. The code is at https://github.com/jerro/dmd/tree/auto-ref. I know next to nothing about DMD, so it could be all kinds of wrong, but it does at least seem to work.
>
> What do you think should happen in this case:
>
> void foo(auto ref int a){}
> void foo(int a){}
> ...
> foo(1);
>
> should this be an error, or should the second overload be called?

IMO the second overload (foo(int a)) should be called and the compiler shouldn't do anymore, because all necessary functions exists.

> And what about this:
>
> void foo(auto ref int a){}
> void foo(ref int a){}

IMO the auto ref function should be replaced by void foo(int a){ }. Then all necessary functions exists also.

Nice work so far, but I don't see any tests for it.
I hope it will be merged in this release.
December 30, 2012
On Sunday, 30 December 2012 at 13:57:26 UTC, Namespace wrote:
>> I've played with this a bit today. The code is at https://github.com/jerro/dmd/tree/auto-ref. I know next to nothing about DMD, so it could be all kinds of wrong, but it does at least seem to work.
>>
>> What do you think should happen in this case:
>>
>> void foo(auto ref int a){}
>> void foo(int a){}
>> ...
>> foo(1);
>>
>> should this be an error, or should the second overload be called?
>
> IMO the second overload (foo(int a)) should be called and the compiler shouldn't do anymore, because all necessary functions exists.
>
>> And what about this:
>>
>> void foo(auto ref int a){}
>> void foo(ref int a){}

> IMO the auto ref function should be replaced by void foo(int a){ }. Then all necessary functions exists also.

These aren't template functions. They must both be generated, whether they are used or not. And if they are both generated, name mangling for auto ref must be different, or the linker will complain.

>
> Nice work so far, but I don't see any tests for it.
> I hope it will be merged in this release.

Don't get your hopes up. This could have all kinds of problems, for example, it doesn't work for const auto ref yet. And even if it worked perfectly it's probably to late to merge it in this release.
December 30, 2012
Just hope for the best. Did you create a pull request?
December 30, 2012
On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
> Just hope for the best. Did you create a pull request?

No. I need to first make it work correctly with const at the very least.
December 30, 2012
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
> On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
>> Just hope for the best. Did you create a pull request?
>
> No. I need to first make it work correctly with const at the very least.

You should hurry up, it seems that Walter will official release soon.
January 01, 2013
On Sunday, 30 December 2012 at 16:11:44 UTC, jerro wrote:
> On Sunday, 30 December 2012 at 16:00:22 UTC, Namespace wrote:
>> Just hope for the best. Did you create a pull request?
>
> No. I need to first make it work correctly with const at the very least.

Sorry if I seem intrusive, but how does it look? Do you have it so far that it works with const?
January 01, 2013
On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis wrote:
> On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
>> Snap. You got me.
>
> It wouldn't matter if the function accepted its argument by value. You'd still be returning a reference to a variable that doesn't exist anymore.

 So what if it does exist? Say the temporary lives as long as the current scope lives?
January 01, 2013
On Tuesday, 1 January 2013 at 08:49:29 UTC, Era Scarecrow wrote:
> On Monday, 24 December 2012 at 19:09:35 UTC, Jonathan M Davis wrote:
>> On Monday, December 24, 2012 20:03:24 monarch_dodra wrote:
>>> Snap. You got me.
>>
>> It wouldn't matter if the function accepted its argument by value. You'd still be returning a reference to a variable that doesn't exist anymore.
>
> So what if it does exist? Say the temporary lives as long as the current scope lives?

 Make that the scope of the variable it's being assigned to...