www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Possible enhancement: Concise return statements

reply Timon Gehr <timon.gehr gmx.ch> writes:
Currently, when using delegates in D, there is 'return' all over the place.
Eg:
map!((a){return a*foo(a);})(arr);

Many delegates consist of only one return statement. Writing 'return' is 
rather inconvenient and adds to the general noise.

Now, I would like to propose to enhance the language in the following way:

'When the last ExpressionStatement in a function body is missing the 
';', it is implicitly returned.'

The example above would become:

map!((a){a*foo(a)})(arr);

Multi-statement delegates would also be supported:
{auto y=x;++x;y}();

Probably, it would be best to disallow to use both forms of return 
statement simultaneously:

{if(x) return y; z} // error

I feel that this would add much to the language for both code 
readability and pleasure of writing code, especially in a functional 
style. As it is a purely additive change (currently, such code is always 
a syntax error), no existing code would be broken.


(One indirect benefit would be that we could then require lazy arguments 
to be pure. Call by name would then be implemented by eg:

int x;
foo({x<100},{x++}); // it is evident at the call site what is going on)



Any thoughts on this?
Aug 15 2011
next sibling parent simendsjo <simendsjo gmail.com> writes:
On 15.08.2011 12:54, Timon Gehr wrote:
 Currently, when using delegates in D, there is 'return' all over the place.
 Eg:
 map!((a){return a*foo(a);})(arr);

 Many delegates consist of only one return statement. Writing 'return' is
 rather inconvenient and adds to the general noise.

 Now, I would like to propose to enhance the language in the following way:

 'When the last ExpressionStatement in a function body is missing the
 ';', it is implicitly returned.'

Seems a bit error prone. I'd rather have a rule that, "If the delegate body only consists of a single expression, it's implicitly returned".
 The example above would become:

 map!((a){a*foo(a)})(arr);

"a*foo(a);"
 Multi-statement delegates would also be supported:
 {auto y=x;++x;y}();

Error, need return y;
 Probably, it would be best to disallow to use both forms of return
 statement simultaneously:

 {if(x) return y; z} // error

Error, use "x ? y : z;"
 I feel that this would add much to the language for both code
 readability and pleasure of writing code, especially in a functional
 style. As it is a purely additive change (currently, such code is always
 a syntax error), no existing code would be broken.


 (One indirect benefit would be that we could then require lazy arguments
 to be pure. Call by name would then be implemented by eg:

 int x;
 foo({x<100},{x++}); // it is evident at the call site what is going on)



 Any thoughts on this?

Aug 15 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-15 12:54, Timon Gehr wrote:
 Currently, when using delegates in D, there is 'return' all over the place.
 Eg:
 map!((a){return a*foo(a);})(arr);

 Many delegates consist of only one return statement. Writing 'return' is
 rather inconvenient and adds to the general noise.

 Now, I would like to propose to enhance the language in the following way:

 'When the last ExpressionStatement in a function body is missing the
 ';', it is implicitly returned.'

 The example above would become:

 map!((a){a*foo(a)})(arr);

 Multi-statement delegates would also be supported:
 {auto y=x;++x;y}();

 Probably, it would be best to disallow to use both forms of return
 statement simultaneously:

 {if(x) return y; z} // error

 I feel that this would add much to the language for both code
 readability and pleasure of writing code, especially in a functional
 style. As it is a purely additive change (currently, such code is always
 a syntax error), no existing code would be broken.


 (One indirect benefit would be that we could then require lazy arguments
 to be pure. Call by name would then be implemented by eg:

 int x;
 foo({x<100},{x++}); // it is evident at the call site what is going on)



 Any thoughts on this?

Yes, please. In fact I would like that the last expression in all functions and delegates to be automatically returned. When we're talking about improving the delegate syntax I would like to have these two syntaxes for delegates: foo(x => x * x) and foo(x) { x * x } -- /Jacob Carlborg
Aug 15 2011
parent reply Mafi <mafi example.org> writes:
Am 15.08.2011 16:01, schrieb Jacob Carlborg:
 On 2011-08-15 12:54, Timon Gehr wrote:
 Currently, when using delegates in D, there is 'return' all over the
 place.
 Eg:
 map!((a){return a*foo(a);})(arr);

 Many delegates consist of only one return statement. Writing 'return' is
 rather inconvenient and adds to the general noise.

 Now, I would like to propose to enhance the language in the following
 way:

 'When the last ExpressionStatement in a function body is missing the
 ';', it is implicitly returned.'

 The example above would become:

 map!((a){a*foo(a)})(arr);

 Multi-statement delegates would also be supported:
 {auto y=x;++x;y}();

 Probably, it would be best to disallow to use both forms of return
 statement simultaneously:

 {if(x) return y; z} // error

 I feel that this would add much to the language for both code
 readability and pleasure of writing code, especially in a functional
 style. As it is a purely additive change (currently, such code is always
 a syntax error), no existing code would be broken.


 (One indirect benefit would be that we could then require lazy arguments
 to be pure. Call by name would then be implemented by eg:

 int x;
 foo({x<100},{x++}); // it is evident at the call site what is going on)



 Any thoughts on this?

Yes, please. In fact I would like that the last expression in all functions and delegates to be automatically returned. When we're talking about improving the delegate syntax I would like to have these two syntaxes for delegates: foo(x => x * x) and foo(x) { x * x }

I personally don't like number one but that's subjective. The second has a serious problem: it makes the grammer context sensitive. You can't distinguish such a call from a local function definition. Therefore I suggest: foo(x) do (...){ ... } 'do' is already a keyword but only once ten years used for a do...while loop. If the functions are named correctly it reads perfectly: when!SomeEvent do (ev) { } where when is: void when(T : Event)(void delegate(T) reaction) {...}
Aug 15 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-08-15 17:04, Mafi wrote:
 Am 15.08.2011 16:01, schrieb Jacob Carlborg:
 Yes, please. In fact I would like that the last expression in all
 functions and delegates to be automatically returned.

 When we're talking about improving the delegate syntax I would like to
 have these two syntaxes for delegates:

 foo(x => x * x)

 and

 foo(x) {
 x * x
 }

I personally don't like number one but that's subjective. The second has a serious problem: it makes the grammer context sensitive. You can't distinguish such a call from a local function definition. Therefore I suggest: foo(x) do (...){ ... }

How is that? A function definition requires a type and a name, not just a name. BTW, it works find in Scala, but that might be because functions start with the "def" keyword.
 'do' is already a keyword but only once ten years used for a do...while
 loop. If the functions are named correctly it reads perfectly:
 when!SomeEvent do (ev) {
 }

 where when is:
 void when(T : Event)(void delegate(T) reaction) {...}

I would rather not have the "do" keyword there. -- /Jacob Carlborg
Aug 15 2011
prev sibling next sibling parent Mehrdad <wfunction hotmail.com> writes:
On 8/15/2011 3:54 AM, Timon Gehr wrote:
 Currently, when using delegates in D, there is 'return' all over the 
 place.
 Eg:
 map!((a){return a*foo(a);})(arr);

 Many delegates consist of only one return statement. Writing 'return' 
 is rather inconvenient and adds to the general noise

This is precisely the reason for C#'s a => b notation. Maybe it's time to adopt it?
Aug 15 2011
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Timon Gehr:

 'When the last ExpressionStatement in a function body is missing the 
 ';', it is implicitly returned.'

I remember others in past suggest the same idea. This is a good sign because it means it's a natural enough syntax for D programmers.
 map!((a){a*foo(a)})(arr);

You have picked a suboptimal example, because D/Phobos already allows you write this (because the delegate uses only global names beside its arguments): map!q{ a * foo(a) }(arr);
 Multi-statement delegates would also be supported:
 {auto y=x;++x;y}();

Optional return keyword for multi-statement code is not a good idea in D, despite similar blocks give in Ruby. Decreasing tidiness for a small syntactical convenience is often a bad idea.
 Any thoughts on this?

Time ago someone (me too) has suggested a syntax like this: map!({ a => a * foo(a) })(arr); To replace this syntax: map!((a){ return a * foo(a); })(arr); But overall I don't see this as a large improvement. It's just nice. Maybe for D3. In my opinion a good "yield" (and generators) is syntax sugar that's rather more important than optionally omitting return. It changes the way you write code. Omitting a return doesn't change my way of using delegates, it just makes it a bit shorter. Bye, bearophile
Aug 15 2011
parent David Nadlinger <see klickverbot.at> writes:
On 8/15/11 7:53 PM, bearophile wrote:
 Timon Gehr:
 map!((a){a*foo(a)})(arr);

You have picked a suboptimal example, because D/Phobos already allows you write this (because the delegate uses only global names beside its arguments): map!q{ a * foo(a) }(arr);

No! As long as foo() is not in the »blessed« set of modules imported by std.functional, there is no way to access it from a string literal lambda. David
Aug 15 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)
Aug 15 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 15 Aug 2011 15:00:03 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the  
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Not that I'm for or against this issue, I think comparing this proposal to the for + empty statement is completely disproportionate. What is going to happen if someone adds an extra ';' ? Compiler error ("no return statement") What is going to happen if someone accidentally does not put a semicolon on the last statement? If it's not the correct return type, it's an error, otherwise, it's likely what the person wanted. It's not like a return can happen in the middle, it *only* comes in to play as the last line of the function. I agree with others that if this were to be implemented, only allowing the short form on single-expression functions would be a good conservative start. But again, I don't frequently use delegates like this, so I'm somewhat neutral. -Steve
Aug 15 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-15 21:17, Steven Schveighoffer wrote:
 On Mon, 15 Aug 2011 15:00:03 -0400, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Not that I'm for or against this issue, I think comparing this proposal to the for + empty statement is completely disproportionate. What is going to happen if someone adds an extra ';' ? Compiler error ("no return statement") What is going to happen if someone accidentally does not put a semicolon on the last statement? If it's not the correct return type, it's an error, otherwise, it's likely what the person wanted. It's not like a return can happen in the middle, it *only* comes in to play as the last line of the function. I agree with others that if this were to be implemented, only allowing the short form on single-expression functions would be a good conservative start. But again, I don't frequently use delegates like this, so I'm somewhat neutral. -Steve

The reason I don't use delegates as much as I would like to is just because of things like this, i.e. the syntax is too verbose. -- /Jacob Carlborg
Aug 15 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2011 12:17 PM, Steven Schveighoffer wrote:
 What is going to happen if someone adds an extra ';' ? Compiler error ("no
 return statement")

Such lambdas are often used with 'auto' returns, so you'd get no compiler error, but a subtle in the way your program works.
Aug 15 2011
next sibling parent David Nadlinger <see klickverbot.at> writes:
On 8/15/11 10:05 PM, Walter Bright wrote:
 On 8/15/2011 12:17 PM, Steven Schveighoffer wrote:
 What is going to happen if someone adds an extra ';' ? Compiler error
 ("no
 return statement")

Such lambdas are often used with 'auto' returns, so you'd get no compiler error, but a subtle in the way your program works.

Do you have an actual example for this in mind? In every situation where you actually use the return value, »changing its type to void« would give you tons of compiler errors. If you are not using the return value anyway – who cares? David
Aug 15 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2011 1:13 PM, Steven Schveighoffer wrote:
 On Mon, 15 Aug 2011 16:05:31 -0400, Walter Bright <newshound2 digitalmars.com>
 wrote:

 On 8/15/2011 12:17 PM, Steven Schveighoffer wrote:
 What is going to happen if someone adds an extra ';' ? Compiler error ("no
 return statement")

Such lambdas are often used with 'auto' returns, so you'd get no compiler error, but a subtle in the way your program works.

So you're saying it becomes a void function? This still is not bad: 1. Caller is expecting it not to be void, compiler error 2. Caller is not using the return value, who cares?

With struct destructors, (2) is a problem. Overloading can also be a problem.
Aug 15 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2011 2:00 PM, Jonathan M Davis wrote:
 It would be a big problem with regard to functions in general IMHO, but how do
 struct destructors and overloading apply to lambdas? It at least _seems_ like
 it would be possible to make it so that single-statement lambdas which have no
 return or ; but return the result of that statement would work without any
 ambiguities.

Struct destructors and postblits execute arbitrary code. A function returning such a struct would build the return value in the caller's stack. Overloading comes when a lambda is passed as a template argument, becoming a function pointer, which is then used as an argument to an overloaded function.
Aug 15 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:

 What is going to happen if someone adds an extra ';' ?  Compiler error  
 ("no return statement")

A specific syntax, usable just for delegates that are not void seems to solve some problems: { a => a * foo(a) } // OK { a, b => a * b } // OK { int a, int b => a * b } // OK { a => a * 6; } // syntax error { a => return a * 6 } // syntax error { a, b => a *= 6; a * b } // syntax error? Bye, bearophile
Aug 15 2011
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-08-15 21:00, Walter Bright wrote:
 On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Can't we always automatically return the last expression, even if it ends with a semicolon? -- /Jacob Carlborg
Aug 15 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/15/2011 12:19 PM, Jacob Carlborg wrote:
 Can't we always automatically return the last expression, even if it ends with
a
 semicolon?

It interferes with auto return typing (such as void returns).
Aug 15 2011
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-15 22:06, Walter Bright wrote:
 On 8/15/2011 12:19 PM, Jacob Carlborg wrote:
 Can't we always automatically return the last expression, even if it
 ends with a
 semicolon?

It interferes with auto return typing (such as void returns).

You mean that instead of void it would return something? I'm working quite a lot in Ruby, which automatically returns the last expression in all methods and lambdas. I'm certain I'm implicitly returning a lot of values that I don't know about and in D these functions would be declared "void". I have no problem in Ruby with this, it's working great. -- /Jacob Carlborg
Aug 15 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-15 22:06, Walter Bright wrote:
 On 8/15/2011 12:19 PM, Jacob Carlborg wrote:
 Can't we always automatically return the last expression, even if it
 ends with a
 semicolon?

It interferes with auto return typing (such as void returns).

Don't know if this apply in this case but couldn't all lambdas/delegates that return something be implicitly converted to delegate/lambda of the same signature but that returns void instead. I would be like calling the delegate but not doing anything with the return value. -- /Jacob Carlborg
Aug 16 2011
prev sibling parent pillsy <pillsbury gmail.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article
 On 8/15/2011 12:19 PM, Jacob Carlborg wrote:

 Can't we always automatically return the last expression, even if it ends with
a
 semicolon?


 It interferes with auto return typing (such as void returns).

Ignoring uninteresting return values in functions performed for side-effects is idiomatic in every language that has both return values and side-effects. How often do people actually look at the return value of printf? In the unusual case where it is important to disambiguate, the function can always be declared void, or an explicit return statement can still be used. The less ceremony necessary to define a function, the better, IMO. Cheers, Pillsy
Aug 17 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/15/11 2:19 PM, Jacob Carlborg wrote:
 On 2011-08-15 21:00, Walter Bright wrote:
 On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Can't we always automatically return the last expression, even if it ends with a semicolon?

Then two semicolons mean return void :o). Andrei
Aug 15 2011
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/15/2011 11:15 PM, Andrew Wiley wrote:
 On Mon, Aug 15, 2011 at 1:57 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 8/15/11 2:19 PM, Jacob Carlborg wrote:

         On 2011-08-15 21:00, Walter Bright wrote:

             On 8/15/2011 3:54 AM, Timon Gehr wrote:

                 'When the last ExpressionStatement in a function body is
                 missing the
                 ';', it is
                 implicitly returned.'


             This has been proposed several times before, it was also
             proposed for
             C++0x. The difficulty is it makes having a ; or not
             substantially alter
             the semantics. The history of these languages is that the
             presence or
             absence of ; can be hard to spot, as in:

             for (int i = 0; i < 10; i++);
             ... do this ...

             which has cost at least one expert developer I know an
             entire afternoon
             staring at it convinced there was a compiler bug because his
             loop
             executed only once.

             (And this is why D disallows this syntax.)


         Can't we always automatically return the last expression, even if it
         ends with a semicolon?


     Then two semicolons mean return void :o).


 If you want void, you have to use this as your last expression:
 ...- --- .. -..;

Two semicolons means the last statement is an empty statement, so Andrei's suggestion would be sensible if the last expression was implicitly returned all the time ;) Topic: So, I'm not convinced that accidents related to writing one surplus ; or leaving one ; away would lead to hard to find and impossible to statically catch bugs. (After all, such accidents would *always* make it into the type signature of the function.) As this apparently has been discussed before, does anyone actually have a real world example where it could be shown to be problematic?
Aug 15 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-08-15 22:57, Andrei Alexandrescu wrote:
 On 8/15/11 2:19 PM, Jacob Carlborg wrote:
 On 2011-08-15 21:00, Walter Bright wrote:
 On 8/15/2011 3:54 AM, Timon Gehr wrote:
 'When the last ExpressionStatement in a function body is missing the
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Can't we always automatically return the last expression, even if it ends with a semicolon?

Then two semicolons mean return void :o). Andrei

Make two semicolons a syntax error. -- /Jacob Carlborg
Aug 16 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 15 Aug 2011 16:05:31 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 8/15/2011 12:17 PM, Steven Schveighoffer wrote:
 What is going to happen if someone adds an extra ';' ? Compiler error  
 ("no
 return statement")

Such lambdas are often used with 'auto' returns, so you'd get no compiler error, but a subtle in the way your program works.

So you're saying it becomes a void function? This still is not bad: 1. Caller is expecting it not to be void, compiler error 2. Caller is not using the return value, who cares? -Steve
Aug 15 2011
prev sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--001636c5c18b26ffed04aa91c6c2
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 15, 2011 at 1:57 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 On 8/15/11 2:19 PM, Jacob Carlborg wrote:

 On 2011-08-15 21:00, Walter Bright wrote:

 On 8/15/2011 3:54 AM, Timon Gehr wrote:

 'When the last ExpressionStatement in a function body is missing the
 ';', it is
 implicitly returned.'

This has been proposed several times before, it was also proposed for C++0x. The difficulty is it makes having a ; or not substantially alter the semantics. The history of these languages is that the presence or absence of ; can be hard to spot, as in: for (int i = 0; i < 10; i++); ... do this ... which has cost at least one expert developer I know an entire afternoon staring at it convinced there was a compiler bug because his loop executed only once. (And this is why D disallows this syntax.)

Can't we always automatically return the last expression, even if it ends with a semicolon?

Then two semicolons mean return void :o).

If you want void, you have to use this as your last expression: ...- --- .. -..; --001636c5c18b26ffed04aa91c6c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Aug 15, 2011 at 1:57 PM, Andrei Alexandr= escu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erdani.org"=
SeeWebsiteForEmail erdani.org</a>&gt;</span> wrote:<br><blockquote class=

ing-left:1ex;"> <div><div></div><div class=3D"h5">On 8/15/11 2:19 PM, Jacob Carlborg wrote:= <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 2011-08-15 21:00, Walter Bright wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 8/15/2011 3:54 AM, Timon Gehr wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> &#39;When the last ExpressionStatement in a function body is missing the<br=

implicitly returned.&#39;<br> </blockquote> <br> This has been proposed several times before, it was also proposed for<br> C++0x. The difficulty is it makes having a ; or not substantially alter<br> the semantics. The history of these languages is that the presence or<br> absence of ; can be hard to spot, as in:<br> <br> for (int i =3D 0; i &lt; 10; i++);<br> ... do this ...<br> <br> which has cost at least one expert developer I know an entire afternoon<br> staring at it convinced there was a compiler bug because his loop<br> executed only once.<br> <br> (And this is why D disallows this syntax.)<br> </blockquote> <br> Can&#39;t we always automatically return the last expression, even if it<br=

</blockquote> <br></div></div> Then two semicolons mean return void :o).</blockquote><div><br></div><div>I= f you want void, you have to use this as your last expression:</div><div><s= pan class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: = 13px; line-height: 21px; background-color: rgb(255, 255, 255); ">...-=A0---= =A0..=A0-..;</span>=A0</div> </div><br> --001636c5c18b26ffed04aa91c6c2--
Aug 15 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/15/11, Walter Bright <newshound2 digitalmars.com> wrote:
     for (int i = 0; i < 10; i++);
        ... do this ...

 which has cost at least one expert developer I know an entire afternoon
 staring
 at it convinced there was a compiler bug because his loop executed only
 once.

 (And this is why D disallows this syntax.)

I've been meaning to say, DMD caught me doing this at least 2 dozen times over the last year or so. Adding this to the language was a great move.
Aug 15 2011
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, August 15, 2011 13:31 Walter Bright wrote:
 On 8/15/2011 1:13 PM, Steven Schveighoffer wrote:
 On Mon, 15 Aug 2011 16:05:31 -0400, Walter Bright
 <newshound2 digitalmars.com>
 
 wrote:
 On 8/15/2011 12:17 PM, Steven Schveighoffer wrote:
 What is going to happen if someone adds an extra ';' ? Compiler error
 ("no return statement")

Such lambdas are often used with 'auto' returns, so you'd get no compiler error, but a subtle in the way your program works.

So you're saying it becomes a void function? This still is not bad: 1. Caller is expecting it not to be void, compiler error 2. Caller is not using the return value, who cares?

With struct destructors, (2) is a problem. Overloading can also be a problem.

It would be a big problem with regard to functions in general IMHO, but how do struct destructors and overloading apply to lambdas? It at least _seems_ like it would be possible to make it so that single-statement lambdas which have no return or ; but return the result of that statement would work without any ambiguities. - Jonathan M Davis
Aug 15 2011