www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static property without return type

reply "Michael" <pr m1xa.com> writes:
Why Dmd accepts?

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

     }
}

Dmd 2.062 Win 64
Mar 16 2013
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
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.
Mar 16 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Mar 16 2013
parent Artur Skawina <art.08.09 gmail.com> writes:
On 03/17/13 19:48, Andrej Mitrovic wrote:
 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

That's because "auto ref" is a hack. IOW "auto ref" != "auto" + "ref", just as "static if" != "static" + "if". artur
Mar 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Mar 16 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Mar 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Mar 16 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
Mar 16 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Mar 16 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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
Mar 17 2013
prev sibling next sibling parent "Alvaro" <alvaro-dot-segura gmail.com> writes:
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?
Mar 17 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/17/13, Artur Skawina <art.08.09 gmail.com> wrote:
 That's because "auto ref" is a hack.
 IOW "auto ref" != "auto" + "ref", just as "static if" != "static" + "if".

Both auto and auto ref are documented features, type inference with any storage class is not a documented feature.
Mar 17 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 17 March 2013 at 22:11:27 UTC, Andrej Mitrovic wrote:
 On 3/17/13, Artur Skawina <art.08.09 gmail.com> wrote:
 That's because "auto ref" is a hack.
 IOW "auto ref" != "auto" + "ref", just as "static if" != 
 "static" + "if".

Both auto and auto ref are documented features, type inference with any storage class is not a documented feature.

Actually it is, and there is example with "static i = 3" but functions are not mentioned explicitly. http://dlang.org/declaration.html , "Implicit Type Inference"
Mar 17 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 17 March 2013 at 22:11:27 UTC, Andrej Mitrovic wrote:
 On 3/17/13, Artur Skawina <art.08.09 gmail.com> wrote:
 That's because "auto ref" is a hack.
 IOW "auto ref" != "auto" + "ref", just as "static if" != 
 "static" + "if".

Both auto and auto ref are documented features, type inference with any storage class is not a documented feature.

Yes it is. From the spec (http://dlang.org/declaration.html) -- Implicit 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. The first example is even: static x = 3; Any storage class will do. No need for auto. It's not documented as needed, it's not implied to be needed, and it isn't needed.
Mar 18 2013
prev sibling parent "Michael" <pr m1xa.com> writes:
I see.
I agree with Andrej Mitrovic, it's curious feature, but 
misleading.
Mar 18 2013