There's a need in generic code to have a function take a parameter by ref if it is an lvalue, and by value if it is an rvalue. This can be addressed by making it a template using auto ref:

  T foo(T)(auto ref T x) { ... }

  foo(3)    // call by value
  int y;
  foo(y)    // call by reference

There is also a need to 'transmit' the ref'ness to the return value. This can be done with auto ref:

  auto ref foo(T)(auto ref T x) { return x; }

  foo(3)   =>  int foo(int x)
  foo(y)   =>  ref int foo(ref int x)

This means that the generic forwarding function would look like:

   auto ref foo(alias F, T...)(auto ref T args) { return F(args); }

On 16/12/2009 07:18, Walter Bright wrote:
> There's a need in generic code to have a function take a parameter by
> ref if it is an lvalue, and by value if it is an rvalue. This can be
> addressed by making it a template using auto ref:
>
> T foo(T)(auto ref T x) { ... }
>
> foo(3) // call by value
> int y;
> foo(y) // call by reference
>
> There is also a need to 'transmit' the ref'ness to the return value.
> This can be done with auto ref:
>
> auto ref foo(T)(auto ref T x) { return x; }
>
> foo(3) => int foo(int x)
> foo(y) => ref int foo(ref int x)
>
> This means that the generic forwarding function would look like:
>
> auto ref foo(alias F, T...)(auto ref T args) { return F(args); }

Just to confirm (I'm just getting into D, so I don't know much about the language, still learning), but the idea is to apply 'auto' not only to types but also to storage classes? As in 'automatically apply ref in the case of lvalue'?

If so I'm a little confused by 'auto ref foo(...' - if auto ref here is also simply an 'apply ref in the case of lvalue', then where is the return type being inferred from?

Dahl

Mikhail Dahl wrote:
> Just to confirm (I'm just getting into D, so I don't know much about the language, still learning), but the idea is to apply 'auto' not only to types but also to storage classes? As in 'automatically apply ref in the case of lvalue'?

Yes, exactly.


> If so I'm a little confused by 'auto ref foo(...' - if auto ref here is also simply an 'apply ref in the case of lvalue', then where is the return type being inferred from?

From the return statement in the body of the function.

On 16/12/2009 07:41, Walter Bright wrote:
> Mikhail Dahl wrote:
>> Just to confirm (I'm just getting into D, so I don't know much about
>> the language, still learning), but the idea is to apply 'auto' not
>> only to types but also to storage classes? As in 'automatically apply
>> ref in the case of lvalue'?
>
> Yes, exactly.
>
>
>> If so I'm a little confused by 'auto ref foo(...' - if auto ref here
>> is also simply an 'apply ref in the case of lvalue', then where is the
>> return type being inferred from?
>
>  From the return statement in the body of the function.

Ah yeah sorry, it's too obvious. That's what happens at 8am when you've had no sleep.

Mikhail Dahl wrote:
> That's what happens at 8am when you've had no sleep.

I know the feeling well. Well enough that I don't even bother trying to code when I feel that way, as after I get some sleep I have to unwind all those "great ideas" I had when overtired.

On Dec 16, 09 15:18, Walter Bright wrote:
> There's a need in generic code to have a function take a parameter by
> ref if it is an lvalue, and by value if it is an rvalue. This can be
> addressed by making it a template using auto ref:
>
> T foo(T)(auto ref T x) { ... }
>
> foo(3) // call by value
> int y;
> foo(y) // call by reference
>
> There is also a need to 'transmit' the ref'ness to the return value.
> This can be done with auto ref:
>
> auto ref foo(T)(auto ref T x) { return x; }
>
> foo(3) => int foo(int x)
> foo(y) => ref int foo(ref int x)
>
> This means that the generic forwarding function would look like:
>
> auto ref foo(alias F, T...)(auto ref T args) { return F(args); }

auto const?

KennyTM~ Wrote:

> auto const?

I was wondering the same thing.

Jason House wrote:
> KennyTM~ Wrote:
> 
>> auto const?
> 
> I was wondering the same thing.

The const transport thing is, unfortunately, a very different problem.

Walter Bright Wrote:

> Jason House wrote:
> > KennyTM~ Wrote:
> > 
> >> auto const?
> > 
> > I was wondering the same thing.
> 
> The const transport thing is, unfortunately, a very different problem.

Of course, but it may still go through bikeshed issues. This morning I read about inout, return, vconst, aconst, sameconst, autoconst, auto const, and bikeshed. At least one of those was in jest :) auto const isn't that bad, and you obviously liked auto ref...

On Wed, 16 Dec 2009 16:46:14 -0500, Jason House <jason.james.house@gmail.com> wrote:

> Walter Bright Wrote:
>
>> Jason House wrote:
>> > KennyTM~ Wrote:
>> >
>> >> auto const?
>> >
>> > I was wondering the same thing.
>>
>> The const transport thing is, unfortunately, a very different problem.
>
> Of course, but it may still go through bikeshed issues. This morning I read about inout, return, vconst, aconst, sameconst, autoconst, auto const, and bikeshed. At least one of those was in jest :) auto const isn't that bad, and you obviously liked auto ref...

I think one of the problems is that ref is a storage class, so it's easy to insert another storage class on top of it.

With the const transport issue, the identifier has to be a type constructor, and needs to decorate types in the same way const can.  i.e.:

identifier(int)[]

but ref isn't like this, you don't see:

ref(int)[]

So if you used auto const, what does this mean:

auto const(int)[]

It looks strange to me.  Remember that you will see this not only in parameter types but in stack variable declarations.

This also makes auto a type constructor, which it is not currently.  I think we have enough multi-meaning keywords.

I don't really care what the keyword turns out to be, but I think it needs to be a single keyword.

-Steve