• Ary Borenszweig (11/11) Aug 12 2009 This compiles and runs in D2:
• bearophile (4/5) Aug 12 2009 More than two months ago I have asked for such feature. Then I have test...
• Ary Borenszweig (33/37) Aug 12 2009 Ah... but it wasn't mentioned anywhere.
• Ary Borenszweig (4/50) Aug 12 2009 Heh, debugging the code revealed that also this condition is present:
• Jarrett Billingsley (13/24) Aug 12 2009 Cool. I'm testing this and it really does seem to be non-templated.
• language_fan (21/22) Aug 12 2009 Who would have guessed! It would help if the compiler knew how to do
• language_fan (8/38) Aug 12 2009 Another case
• Ary Borenszweig (4/35) Aug 12 2009 Now that it also works in Descent I can see it's because function
• Jason House (3/39) Aug 13 2009 When can we look forward to Descent for D2? :)
• Ary Borenszweig (17/57) Aug 13 2009 The lexer and parser are already ported to 2.031 (the latest), and also
• Jarrett Billingsley (4/31) Aug 12 2009 ote:
• Walter Bright (3/4) Aug 13 2009 The support for it is limited, basically the function body cannot have
• Ary Borenszweig (4/9) Aug 14 2009 Do you plan to make it work later? Seems pretty hard as things are right...
• Walter Bright (2/12) Aug 14 2009 It's a low priority.

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? :)

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

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. :)

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.

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

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)

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 '{'

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...

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.

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. :)

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

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.

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.)

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.