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



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 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 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 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 reply "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
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 reply "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
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 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 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 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 reply Andrew Wiley <wiley.andrew.j gmail.com> writes:
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:
...- --- .. -..;
Aug 15 2011
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