compiler should infer last semicolon of culy brace block... it makes lambas look better....

[wm201...@gmail.com]

Good code vs.Bad Code

#define LAMBA [=]

menu1.callback("Log->Clear", LAMBDA() {dosomething1(); dosomthing2()});

^^^ Abouve with Inferred last semi-colon: LOOKS GOOD, but a compiler error. 
Why not make it legal to infer the last semicolon in a curly brace block?


Compiles... but the syntax gets on your nerves:

        menu1.callback("Log->Clear", [=]() {dosomething1(); dosomthing2();}); //extra semicolon at the end


sure Laugh now.  But all those semicolons add up in a large program...


Actually while we are on this one.  I always like the "perl feature of allowing extra "commas" when defining a list.  this feature sames a huge amount of lot of time when writing programs that write programs without all the extra garbage code needed to detect the end of list to remove comma at the end of the list:

GOOD:  (thank you perl)
  vector<string> blah {
    "one",
    "two",
    "three",  // <= extra comma ok... ignored without warn
  };

BAD: (no thanks c++: lighten up a little bit c++ compiler... )
  vector<string> blah {
    "one",
    "two",
.    "three"  // <=== no comma allowed here... now all of my loops need extra if block to detect end of list when writing programs that write programs...
  };

now you are asking... why on earth would anybody ever want to write a program that writes a program?
it happens more often than you think...

[Ville Voutilainen]

On 2 December 2016 at 16:49, <wm201...@gmail.com> wrote:
> GOOD: (thank you perl)
> vector<string> blah {
> "one",
> "two",
> "three", // <= extra comma ok... ignored without warn
> };
>
> BAD: (no thanks c++: lighten up a little bit c++ compiler... )
> vector<string> blah {
> "one",
> "two",
> . "three" // <=== no comma allowed here... now all of my loops need
> extra if block to detect end of list when writing programs that write
> programs...
> };

A comma is allowed there.

[Jakob Riedle]

A comma is allowed there

Truly...

Concerning your Idea:

I like it!

Another Idea: How about making the "return" stmt obsolete, when there is no semicolon (only within a lambda)? How about being able to write

transform(begin(str), end(str), [](auto c){ toupper(c) } );

Why I said it: Because making "return" optional when there is no semicolon makes it a backwards-compatible change!

Just an idea...

[Nicol Bolas]

Look at how it conflicts with what the OP wanted:

menu1.callback("Log->Clear", [=]() {dosomething1(); dosomthing2()});

With his feature, this is still a `void` function. With what you want, it's equivalent to `return dosomething2()`. That might be `void` or it might not. There's no way to tell.

There are already some ideas around for making lambda-as-single-expression easier to write.

[Jakob Riedle]

That might be `void` or it might not. There's no way to tell.

Well, there is also no way to tell, whether "return dosomething2()" is void.

Look here for an Example.

Does this even answer the concerns that you had?

Well, you're right, that single-expression-lambdas are THE solution.

Jakob

[Nicol Bolas]

On Friday, December 2, 2016 at 3:15:43 PM UTC-5, Jakob Riedle wrote:

That might be `void` or it might not. There's no way to tell.

Well, there is also no way to tell, whether "return dosomething2()" is void.

Look here for an Example.

Does this even answer the concerns that you had?

My point is that it isn't clear whether the user wanted "return dosomething2()` or whether they just wanted to call `dosomething2()`. That's why, if we're going to elide the last semicolon in the block, doing that should not change the meaning of the last statement.

[Daniel Boles]

For sure, that seems to be an irresolvable ambiguity that makes
'implied return' a non-starter.

The optional semicolon is cute, I guess, but hardly the main issue with
expressions of the complexity cited here.

[Mikhail Semenov]

The C/C++ rules on semicolons in statements (not declarations) are a bit odd in contrast to other languages like Pascal, where  semicolons are required only between statements in a compound statement (I am using C syntax to show this):

{S1;S2;...;Sn}

But, it also mean that a semicolon is not used before "else" (we could look into this as well, whether it is viable option):

if (a>b) then x=a else x = b

But, in C/C++, there is the ugly switch statement, where semicolons are probably required as well.

In addition, in some languages, the value {S1;S2;...;Sn} is the value of Sn if it is the last executed statement/expression; otherwise it is the value of the expression in the return statement.

All this can probably be implemented in C++, but all the syntactic ambiguities should be carefully examined.

An then we will be able to write

[&y](int x) { y += x; x }

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-pr...@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1480711391.2485.1.camel%40gmail.com.

[Giovanni Piero Deretta]

why is that an issue? if the lambda was not supposed to return anything the result would be dropped anyway. If it is, then either the code works as intended or the compiler will complain loudly if the returned type is not of the expected type.

[Nicol Bolas]

The return value will be dropped at the location where the function gets called, not by the code that called it. Furthermore, this return value becomes part of the functor's calling type if it is deducing the return type. If you get a function pointer from a capture-less lambda, perhaps to pass to some C-based API, you'll get a very confusing compile error somewhere along the line.

Ultimately, I just don't see the point in having a small syntactic change like missing a semicolon have such a radical change in the meaning of a line of code. It would be much better for us to just give people good syntax for expression-only lambdas, while letting a missing semicolon not change the meaning of the code. If a multi-statement lambda needs to return something, then you need to type `return`.

[Thiago Macieira]

Em domingo, 4 de dezembro de 2016, às 10:44:22 PST, Mikhail Semenov escreveu:
> An then we will be able to write
> [&y](int x) { y += x; x }

You're already able to write that.

Are you asking for the code above to change meaning?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

Em segunda-feira, 5 de dezembro de 2016, às 13:09:29 PST, Thiago Macieira
escreveu:

> Em domingo, 4 de dezembro de 2016, às 10:44:22 PST, Mikhail Semenov
escreveu:
> > An then we will be able to write
> > [&y](int x) { y += x; x }
>
> You're already able to write that.
>
> Are you asking for the code above to change meaning?

Oops, never mind, I missed the extra "x".

Which actually means this may not be a good idea.

[Erich Keane]

This seems like a pretty minor thing, I'm not a huge fan of changing the grammar that much in the name of saving single characters.  Others have mentioned the many problems with automatic return type.

That said, 1 feature that I REALLY miss from C# is  the single-line lambdas (https://msdn.microsoft.com/en-us/library/bb397687.aspx).

Essentially:

auto func = (a, b, c) => a + b + c;

Would be the same as:

auto func = [](auto a, auto b, auto c) { return a + b + c;};

[Nicol Bolas]

Because C++ is more complex than C#, what it converts to should be more complex than that, involving `noexcept` and `decltype` deduction of the return expression (for SFINAE purposes). There's a more full discussion of this sort of thing here.

However, don't get your hopes up for typeless parameters.