www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto

reply Ary Borenszweig <ary esperanto.org.ar> writes:
This compiles and runs in D2:

--
import std.stdio;

auto foo() {
     return 1;
}

void main() {
     writefln("%s", foo());
}
--

Since when a non-templated function can have its return type deduced? :)
Aug 12 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:
 Since when a non-templated function can have its return type deduced? :)<
More than two months ago I have asked for such feature. Then I have tested it, and it was already present :-) So I think it's OK, and expected, it helps when you return very complex types (for example lazy templated generators). Bye, bearophile
Aug 12 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:
 Ary Borenszweig:
 Since when a non-templated function can have its return type deduced? :)<
More than two months ago I have asked for such feature. Then I have tested it, and it was already present :-) So I think it's OK, and expected, it helps when you return very complex types (for example lazy templated generators).
Ah... but it wasn't mentioned anywhere. I was asking because I get parser errors with Descent if I write that. I'm trying to see where I made a mistake in porting the parser, but the code for parsing that is: --- /* Look for return type inference for template functions. */ { Token *tk; if (storage_class && token.value == TOKidentifier && (tk = peek(&token))->value == TOKlparen && skipParens(tk, &tk) && peek(tk)->value == TOKlparen) { ts = NULL; } else { ts = parseBasicType(); ts = parseBasicType2(ts); } } --- and there's also a similar code somewhere else. The parser is there after consuming the "auto" token, so token's value is TOKidentifier. As you can see, it checks that the next token is "(", then it peeks past the closing parenthesis and checks that that token is also "(" (for a templated function). So it won't work with non-templated functions. And parseBasicType and parseBasicType2 fail. I'll probably need to debug the C++ code... unless someone can debug it for me and tell me what's going on. :)
Aug 12 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Ary Borenszweig wrote:
 bearophile wrote:
 Ary Borenszweig:
 Since when a non-templated function can have its return type deduced? 
 :)<
More than two months ago I have asked for such feature. Then I have tested it, and it was already present :-) So I think it's OK, and expected, it helps when you return very complex types (for example lazy templated generators).
Ah... but it wasn't mentioned anywhere. I was asking because I get parser errors with Descent if I write that. I'm trying to see where I made a mistake in porting the parser, but the code for parsing that is: --- /* Look for return type inference for template functions. */ { Token *tk; if (storage_class && token.value == TOKidentifier && (tk = peek(&token))->value == TOKlparen && skipParens(tk, &tk) && peek(tk)->value == TOKlparen) { ts = NULL; } else { ts = parseBasicType(); ts = parseBasicType2(ts); } } --- and there's also a similar code somewhere else. The parser is there after consuming the "auto" token, so token's value is TOKidentifier. As you can see, it checks that the next token is "(", then it peeks past the closing parenthesis and checks that that token is also "(" (for a templated function). So it won't work with non-templated functions. And parseBasicType and parseBasicType2 fail. I'll probably need to debug the C++ code... unless someone can debug it for me and tell me what's going on. :)
Heh, debugging the code revealed that also this condition is present: || peek(tk)->value == TOKlcurly so that's why it parses it ok. Ah... mistery solved.
Aug 12 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Aug 12, 2009 at 9:18 AM, Ary Borenszweig<ary esperanto.org.ar> wrot=
e:
 This compiles and runs in D2:

 --
 import std.stdio;

 auto foo() {
 =A0 =A0return 1;
 }

 void main() {
 =A0 =A0writefln("%s", foo());
 }
 --

 Since when a non-templated function can have its return type deduced? :)
Cool. I'm testing this and it really does seem to be non-templated. So of course, the first thing I tried was this: class A { auto foo() { return 0; } } class B : A { auto foo() { return 5; } } but DMD crashes. :P
Aug 12 2009
next sibling parent reply language_fan <foo bar.com.invalid> writes:
Wed, 12 Aug 2009 10:22:22 -0400, Jarrett Billingsley thusly wrote:

 but DMD crashes.  :P
Who would have guessed! It would help if the compiler knew how to do semantic analysis.. here are a couple of additional test cases - a type checker for these can be written in approximately 30 minutes in Prolog or SML or something similar. : foo.d(3): Error: forward reference to foo : foo.d(3): Error: forward reference to inferred return type of function call (())() : (())() : foo.d(1): Error: forward reference to foo : foo.d(1): Error: forward reference to inferred return type of function call foo(a - 1)
Aug 12 2009
parent language_fan <foo bar.com.invalid> writes:
Wed, 12 Aug 2009 15:19:10 +0000, language_fan himself wrote:

 Wed, 12 Aug 2009 10:22:22 -0400, Jarrett Billingsley thusly wrote:
 
 but DMD crashes.  :P
Who would have guessed! It would help if the compiler knew how to do semantic analysis.. here are a couple of additional test cases - a type checker for these can be written in approximately 30 minutes in Prolog or SML or something similar. : foo.d(3): Error: forward reference to foo : foo.d(3): Error: forward reference to inferred return type of function call (())() : (())() : foo.d(1): Error: forward reference to foo : foo.d(1): Error: forward reference to inferred return type of function call foo(a - 1)
Another case : foo.d(2): no identifier for declarator foo : foo.d(2): semicolon expected, not '{'
Aug 12 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jarrett Billingsley wrote:
 On Wed, Aug 12, 2009 at 9:18 AM, Ary Borenszweig<ary esperanto.org.ar> wrote:
 This compiles and runs in D2:

 --
 import std.stdio;

 auto foo() {
    return 1;
 }

 void main() {
    writefln("%s", foo());
 }
 --

 Since when a non-templated function can have its return type deduced? :)
Cool. I'm testing this and it really does seem to be non-templated. So of course, the first thing I tried was this: class A { auto foo() { return 0; } } class B : A { auto foo() { return 5; } } but DMD crashes. :P
Now that it also works in Descent I can see it's because function overloading is treated before function return type inference, and the return types for the functions at those moments are null...
Aug 12 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Ary Borenszweig Wrote:

 Jarrett Billingsley wrote:
 On Wed, Aug 12, 2009 at 9:18 AM, Ary Borenszweig<ary esperanto.org.ar> wrote:
 This compiles and runs in D2:

 --
 import std.stdio;

 auto foo() {
    return 1;
 }

 void main() {
    writefln("%s", foo());
 }
 --

 Since when a non-templated function can have its return type deduced? :)
Cool. I'm testing this and it really does seem to be non-templated. So of course, the first thing I tried was this: class A { auto foo() { return 0; } } class B : A { auto foo() { return 5; } } but DMD crashes. :P
Now that it also works in Descent I can see it's because function overloading is treated before function return type inference, and the return types for the functions at those moments are null...
When can we look forward to Descent for D2? :) Also, what kind of porting issues did you have? How could it be made simpler? I'm assuming that whatever makes your work easier also helps others customizing their applications for D2.
Aug 13 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Jason House escribió:
 Ary Borenszweig Wrote:
 
 Jarrett Billingsley wrote:
 On Wed, Aug 12, 2009 at 9:18 AM, Ary Borenszweig<ary esperanto.org.ar> wrote:
 This compiles and runs in D2:

 --
 import std.stdio;

 auto foo() {
    return 1;
 }

 void main() {
    writefln("%s", foo());
 }
 --

 Since when a non-templated function can have its return type deduced? :)
Cool. I'm testing this and it really does seem to be non-templated. So of course, the first thing I tried was this: class A { auto foo() { return 0; } } class B : A { auto foo() { return 5; } } but DMD crashes. :P
Now that it also works in Descent I can see it's because function overloading is treated before function return type inference, and the return types for the functions at those moments are null...
When can we look forward to Descent for D2? :)
The lexer and parser are already ported to 2.031 (the latest), and also everything related to that (the public AST, the formatter, the compile-time view, etc.). But I still need to finish porting the semantic analysis. 10 c files remaining. ;-) I could release now with the lexer and parser, but sometimes there are null pointer exceptions and illegal state exceptions because of this lack of ported semantic. I advance little by little each day (or each "free time that I feel like making something"), maybe in some weeks or months I'll finish.
 
 Also, what kind of porting issues did you have? How could it be made simpler?
I'm assuming that whatever makes your work easier also helps others customizing
their applications for D2.
I copied the diff of one part, saw the other part looked the same, so I copied the Java version insted of the C++ version (easier to port, because I don't have to replace "->" with "." and remove the "*" for pointers)... but it looked almost the same, but wasn't the same. Anyway, it doesn't matter much if I make mistakes when porting. When I compile a big project like phobos, errors like that appear right away, and with that I know where the error is and where to look for a solution. :)
Aug 13 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Aug 12, 2009 at 10:22 AM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Wed, Aug 12, 2009 at 9:18 AM, Ary Borenszweig<ary esperanto.org.ar> wr=
ote:
 This compiles and runs in D2:

 --
 import std.stdio;

 auto foo() {
 =A0 =A0return 1;
 }

 void main() {
 =A0 =A0writefln("%s", foo());
 }
 --

 Since when a non-templated function can have its return type deduced? :)
Cool. =A0I'm testing this and it really does seem to be non-templated. So of course, the first thing I tried was this: class A { =A0 =A0auto foo() { return 0; } } class B : A { =A0 =A0auto foo() { return 5; } } but DMD crashes. =A0:P
Reported: http://d.puremagic.com/issues/show_bug.cgi?id=3D3247
Aug 12 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 Since when a non-templated function can have its return type deduced? :)
The support for it is limited, basically the function body cannot have any forward references to other auto functions.
Aug 13 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright wrote:
 Ary Borenszweig wrote:
 Since when a non-templated function can have its return type deduced? :)
The support for it is limited, basically the function body cannot have any forward references to other auto functions.
Do you plan to make it work later? Seems pretty hard as things are right now... (I mean, the order of semantic, semantic2 and semantic3, and what each does.)
Aug 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 Walter Bright wrote:
 Ary Borenszweig wrote:
 Since when a non-templated function can have its return type deduced? :)
The support for it is limited, basically the function body cannot have any forward references to other auto functions.
Do you plan to make it work later? Seems pretty hard as things are right now... (I mean, the order of semantic, semantic2 and semantic3, and what each does.)
It's a low priority.
Aug 14 2009