On Fri, 05 Jun 2015 09:44:09 +0000, Marc Schütz wrote:

> On Friday, 5 June 2015 at 04:39:28 UTC, ketmar wrote:
>> On Fri, 05 Jun 2015 03:56:05 +0000, anonymous wrote:
>>
>>> On Friday, 5 June 2015 at 03:45:18 UTC, ketmar wrote:
>>>> `auto int a`?! it shouldn't be accepted at all!
>>> 
>>> Yeah, but it's the same with "auto ref".
>>
>> `auto ref` has a well-defined meaning. yet `auto int` is nonsence. it's definitely a compiler bug. ;-)
> 
> I don't think so. `auto` is a valid storage class like `const`, `immutable` and `shared`.

p.s. if "auto" is a storage class, the following code should be accepted (while it isn't):

  int foo () { return 42; }

  void main () {
    auto auto i = foo();
  }

as it's logically "an auto-typed var with "auto" storage class".

On Friday, 5 June 2015 at 03:15:46 UTC, anonymous wrote:
> On Friday, 5 June 2015 at 02:38:39 UTC, ketmar wrote:
>> here's dustmited source:
>
> Further reduced:
>
> void unaryFun()(auto int a) pure nothrow @safe @nogc {}
> alias Identity(F) = F;
> void main()
> {
>   unaryFun!()(41);
>   static void fun(int n) pure nothrow @safe @nogc {}
>   alias F = typeof(fun);
>   pragma(msg, F); /* ...(int n) */
>   pragma(msg, Identity!F); /* ...(auto int) */
> }

'auto int' doesn't compile with 2.067.1. I know because this is blocking a PR I'm working on.

On Friday, 5 June 2015 at 10:54:36 UTC, ketmar wrote:
> On Fri, 05 Jun 2015 09:44:09 +0000, Marc Schütz wrote:
>
>> On Friday, 5 June 2015 at 04:39:28 UTC, ketmar wrote:
>>> On Fri, 05 Jun 2015 03:56:05 +0000, anonymous wrote:
>>>
>>>> On Friday, 5 June 2015 at 03:45:18 UTC, ketmar wrote:
>>>>> `auto int a`?! it shouldn't be accepted at all!
>>>> 
>>>> Yeah, but it's the same with "auto ref".
>>>
>>> `auto ref` has a well-defined meaning. yet `auto int` is nonsence. it's
>>> definitely a compiler bug. ;-)
>> 
>> I don't think so. `auto` is a valid storage class like `const`,
>> `immutable` and `shared`.
>
> `auto` is not a storage class, but a `type placeholder`. at least this is
> what i've been told by W or A (sorry, i can't remember the link; i think
> it was somewhere in NG... or in bugzilla...). there is one exception to
> this rule, though: `auto ref`.

My understanding is that `auto` is just C legacy, and originally had the same meaning as in C. But apparently the language has moved away from that over time.

On Fri, 05 Jun 2015 11:07:19 +0000, Meta wrote:

> On Friday, 5 June 2015 at 03:15:46 UTC, anonymous wrote:
>> On Friday, 5 June 2015 at 02:38:39 UTC, ketmar wrote:
>>> here's dustmited source:
>>
>> Further reduced:
>>
>> void unaryFun()(auto int a) pure nothrow @safe @nogc {}
>> alias Identity(F) = F;
>> void main()
>> {
>>   unaryFun!()(41);
>>   static void fun(int n) pure nothrow @safe @nogc {}
>>   alias F = typeof(fun);
>>   pragma(msg, F); /* ...(int n) */
>>   pragma(msg, Identity!F); /* ...(auto int) */
>> }
> 
> 'auto int' doesn't compile with 2.067.1. I know because this is blocking a PR I'm working on.

but it does! both with 2.067.1 downloaded from dlang.org and with git HEAD. it may not do what you expect it to do (i don't know what it should do anyway), but dmd happily accepts that code.

On Fri, 05 Jun 2015 11:53:29 +0000, Marc Schütz wrote:

> My understanding is that `auto` is just C legacy, and originally had the same meaning as in C. But apparently the language has moved away from that over time.

i agree, i think it was a keyword used 'cause it was already used in C. but it's meaning is completely redefined in D.

On Friday, 5 June 2015 at 12:33:35 UTC, ketmar wrote:
> On Fri, 05 Jun 2015 11:53:29 +0000, Marc Schütz wrote:
>
>> My understanding is that `auto` is just C legacy, and originally had the
>> same meaning as in C. But apparently the language has moved away from
>> that over time.
>
> i agree, i think it was a keyword used 'cause it was already used in C.
> but it's meaning is completely redefined in D.

AFAIK auto is a stotage class (like in C). It is the no-op storage and therefore does not not change the stotage or type etc. But in a statement it definitely marks as a declaration because only those can contain storage classes. In D any declaration can omit the type so let it be inferred. That's why this also works:

const x = 10;
static y = 20;
enum z = 30;

Auto is only needed to unambigiously mark a statement as declaration when the lack of type would make it look like an ExpressionStatement. But still

auto int x  = 10;

should work. It's just consistent.

On Friday, 5 June 2015 at 12:32:03 UTC, ketmar wrote:
> but it does! both with 2.067.1 downloaded from dlang.org and with git
> HEAD. it may not do what you expect it to do (i don't know what it should
> do anyway), but dmd happily accepts that code.

Hmm, maybe I'm only on 2.070 then. I'll upgrade and see if it still fails to compile.

On Fri, 05 Jun 2015 15:17:50 +0000, Mafi wrote:

> auto int x  = 10;
> 
> should work. It's just consistent.

then `auto auto` should work too. it's a "declaration mark" + "storage class".

On Friday, 5 June 2015 at 16:26:34 UTC, ketmar wrote:
> On Fri, 05 Jun 2015 15:17:50 +0000, Mafi wrote:
>
>> auto int x  = 10;
>> 
>> should work. It's just consistent.
>
> then `auto auto` should work too. it's a "declaration mark" + "storage
> class".

Well, no. Any storage class marks a declaration just by itself. You don't use it as a "declaration mark" or "storage class", just use a storage class which definitely declares something new. See also http://dlang.org/declaration.html

A declaration is either <StorageClasses(opt) BasicType Declarators> or <AutoDeclaration>. An AutoDeclaration is the one with type inference. And it is marked by any storage class, not just auto (http://dlang.org/declaration.html#AutoDeclaration): <StorageClasses AutoDeclarationX>. Well admittently http://dlang.org/declaration.html#StorageClass does not feature 'auto' as a storage class but this must be an error because the description of AutoDeclaration uses 'auto' in the place of StorageClasses.

It is just about grammar. A declaration needs a type, a storage class or both to not be mistaken for a statement with an assign expression. You use the 'auto' storage class so the statement cannot possibly be an expression when leaving out the type and not using any meaningful storage class.

On Fri, 05 Jun 2015 16:42:25 +0000, Mafi wrote:

> On Friday, 5 June 2015 at 16:26:34 UTC, ketmar wrote:
>> On Fri, 05 Jun 2015 15:17:50 +0000, Mafi wrote:
>>
>>> auto int x  = 10;
>>> 
>>> should work. It's just consistent.
>>
>> then `auto auto` should work too. it's a "declaration mark" + "storage class".
> 
> Well, no. Any storage class marks a declaration just by itself. You don't use it as a "declaration mark" or "storage class", just use a storage class which definitely declares something new. See also http://dlang.org/declaration.html
> 
> A declaration is either <StorageClasses(opt) BasicType Declarators> or <AutoDeclaration>. An AutoDeclaration is the one with type inference. And it is marked by any storage class, not just auto (http://dlang.org/declaration.html#AutoDeclaration): <StorageClasses AutoDeclarationX>. Well admittently http://dlang.org/declaration.html#StorageClass does not feature 'auto' as a storage class but this must be an error because the description of AutoDeclaration uses 'auto' in the place of StorageClasses.
> 
> It is just about grammar. A declaration needs a type, a storage class or both to not be mistaken for a statement with an assign expression. You use the 'auto' storage class so the statement cannot possibly be an expression when leaving out the type and not using any meaningful storage class.

`const int` works, so i can't see why `auto auto` is failing.