Why Dmd accepts?

class E
{
    @property public static pro(Object v)
    {

    }
}

Dmd 2.062 Win 64

On Saturday, 16 March 2013 at 22:34:01 UTC, Michael wrote:
> Why Dmd accepts?
>
> class E
> {
>     @property public static pro(Object v)
>     {
>
>     }
> }
>
> Dmd 2.062 Win 64

It's a (mis)feature. Whenever you have an attribute it acts as if 'auto' is used  if there is no return type.

Personally I've never found this a useful feature.

On 03/16/2013 11:47 PM, Andrej Mitrovic wrote:
> On Saturday, 16 March 2013 at 22:34:01 UTC, Michael wrote:
>> Why Dmd accepts?
>>
>> class E
>> {
>>     @property public static pro(Object v)
>>     {
>>
>>     }
>> }
>>
>> Dmd 2.062 Win 64
>
> It's a (mis)feature.

It is return type deduction.

> Whenever you have an attribute it acts as if 'auto'
> is used  if there is no return type.
>

No, if the return type is missing, it is deduced.
'auto' does not mean type deduction! It's a crutch for the parser. In fact, the meaning of 'auto' is basically carried over unchanged from C.

> Personally I've never found this a useful feature.

Requiring 'auto' would be inconsistent.

On 3/17/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> No, if the return type is missing, it is deduced.

What are you talking about? You can't write:

foo() { return 0; }

> 'auto' does not mean type deduction! It's a crutch for the parser. In fact, the meaning of 'auto' is basically carried over unchanged from C.

auto means something completely different in C.

> Requiring 'auto' would be inconsistent.

It's required without 'static/@safe/@property/pure' and other attributes, it's completely pointless that adding any of these should allow you to avoid specifying the return type.

On Sunday, March 17, 2013 02:06:08 Andrej Mitrovic wrote:
> On 3/17/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
> > No, if the return type is missing, it is deduced.
> 
> What are you talking about? You can't write:
> 
> foo() { return 0; }
> 
> > 'auto' does not mean type deduction! It's a crutch for the parser. In fact, the meaning of 'auto' is basically carried over unchanged from C.
> 
> auto means something completely different in C.

Yeah. All auto means in C is that the variable has local lifetime. At this point, in C, it's completely pointless, because that's the default (you'd have to use something like static or register to make it otherwise).

D's auto is the basically the same as C++11's auto, which means that the type is inferred, which is something completely different.

- Jonathan M Davis

On Sunday, 17 March 2013 at 01:06:22 UTC, Andrej Mitrovic wrote:
> On 3/17/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> No, if the return type is missing, it is deduced.
>
> What are you talking about? You can't write:
>
> foo() { return 0; }

Timon is right here. The reason you cannot write that is because the parser needs the auto crutch. Basically, the parser just needs to see at least one "storage class" before the function identifier. Note that "storage class" here includes things like pure, which isn't really a storage class (see http://dlang.org/declaration.html#StorageClass)

Note that you can write:

const foo() { return 0; }

Type is deduced here, but the presence of const means that the parser doesn't need any other storage class. auto in D actually just means "I don't want to use any other storage class", the type deduction is triggered by the lack of return type.

On Sunday, 17 March 2013 at 02:41:18 UTC, Jonathan M Davis wrote:
> D's auto is the basically the same as C++11's auto, which means that the type
> is inferred, which is something completely different.

Not quite, in C++11, auto is required for type inference, in D it isn't.

Here's all the D spec says about type inference:

"If a declaration starts with a StorageClass and has a NonVoidInitializer from which the type can be inferred, the type on the declaration can be omitted."

No mention of auto. Any storage class will do.

On Sunday, 17 March 2013 at 02:41:18 UTC, Jonathan M Davis wrote:
> On Sunday, March 17, 2013 02:06:08 Andrej Mitrovic wrote:
>> On 3/17/13, Timon Gehr <timon.gehr@gmx.ch> wrote:
>> > No, if the return type is missing, it is deduced.
>> 
>> What are you talking about? You can't write:
>> 
>> foo() { return 0; }
>> 
>> > 'auto' does not mean type deduction! It's a crutch for the parser. In
>> > fact, the meaning of 'auto' is basically carried over unchanged from C.
>> 
>> auto means something completely different in C.
>
> Yeah. All auto means in C is that the variable has local lifetime. At this
> point, in C, it's completely pointless, because that's the default (you'd have
> to use something like static or register to make it otherwise).
>
> D's auto is the basically the same as C++11's auto, which means that the type
> is inferred, which is something completely different.
>

Timon is right. D need at least one storage class to trigger type inference. auto is basically a storage class that does nothing in D.

On 3/17/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> auto in D actually just means "I don't want to use any other storage class"

>From the user's perspective auto means more:

int x;
ref refRet() { return x; }  // ok
ref refRet() { return 1; }  // disallowed

auto ref autoRet() { return x; }  // ok
auto ref autoRet() { return 1; }  // ok

On Saturday, 16 March 2013 at 22:34:01 UTC, Michael wrote:
> Why Dmd accepts?
>
> class E
> {
>     @property public static pro(Object v)
>     {
>
>     }
> }
>

My guess is this: If it takes an argument (Object v) I assume it is a *setter*, so it does not need to return anything. Then, the non-written type is *auto* and is deduced to be *void*. Right?