auto ref

[Steven Schveighoffer]

On Wed, 16 Dec 2009 16:46:14 -0500, Jason House  
<jason.james.house at 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