I can see in your mail 2 main inquiries:

> 1- How is it not type safe?
if the deduced returned type is not the intended returned type, this will
lead to unsafe results.
according to the specification (with a very simple example if a class
convert to POD then return *this can result in the POD value returned
instead of the instance of the class (section 4 in 5.2.1) , I agree that
the
rules are specified, but all this unnecessary complexity if return type is
enforced just as in functions and all this only to try to avoid the
specifying the parameters and the return type as mandatory steps in
defining
the lambda


>2- This is a syntactic detail/"language spirit"/
Of course semantics is part of the language spirit and should stay
consistent when possible, I did not see any reason to break it that by
introduction of the lambda expression and if it is as the suggestion it
will
give immediate click to the one who just learned functions and members
functions and no need to learn the exceptions if it is a lambda function,
consistency is always a key in language success and C++ has a good history
with it, why to break it,, for no reason.

[ lambda-capture] return-type ( parameter-declaration-clause )
attribute-specifier optional  mutable optional  exception-specification
optional

For sure the above it is much safer to program with well specified returned
type specially if the programmer wants the auto as return type it is still
possible.

"CornedBee" <wasti.redl@gmx.net> wrote in message
news:62fe51af-8e52-4d35-819b-0777456530fa@v30g2000yqm.googlegroups.com...
> On Nov 16, 2:09 am, "Abdulla Herzallah" <a...@zoomio.com> wrote:
>> As the new standard allows to eliminate the parameters parenthesis and
>> return type, that will create a more loose type checking and should not
>> be
>> necessary, this way the minimum lambda expression as per the standard is:
>> []{} it could be looked as "cool" but it is not type safe.
>
> How is it not type safe? I think you misunderstand what type safety
> means.
>
>> The following suggestion is more in line with the  C++ language "spirit"
>> where the returned value should be defined before the parameter
>> definition
>
> This is a syntactic detail, not a part of the C++ language spirit. The
> C++ language spirit is, according to D&E, about extensibility through
> libraries and modularity of language features (the "don't pay for what
> you don't use" maxim).
>
> All in all, what are you really complaining about? That the return
> type is no longer in the front? If only function declarations had
> looked like lambdas from the start, C++ would be a lot easier to parse
> - there wouldn't be the ambiguity between a function declaration and
> an initialized object.
>
> Sebastian
>
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Nov 16, 1:09 am, "Abdulla Herzallah" <a...@zoomio.com> wrote:

> The lambda expression is a member function definition and is adding two
> things to function definition which should not break that basic common
> practice of defining functions "the C++ spirit"
> 1- the capture scope variables to the function
> 2- unnamed function name

Those are kind of the point of the feature: introducing unnamed
closures to better support functional programming.
Naming them makes no sense, it actually prevents the language from
generating new functions, which is a requirement of higher-order
programming. If you want to name the function, simply assign it to a
variable that you are naming.


> Specifically speaking is the returned type, which is becoming *unnecessary*
> complex (being deduced from the trailing-return-type) and not inline with
> the way functions are defined in C++ and also adding complexity for compiler
> writers as well.

The return type needs to appear in the declaration.
Sometimes you can deduce it from the definition, sometimes you can't.

It also needs to be after the list of the argument so that the
arguments themselves are in scope in the declaration of the return
type.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I am sorry for the long message but I am bit surprised to see that the
Lambda expressions signature is not inline with the language "spirit" i.e
the function definition is not the standard way to define a function and
unnecessary complexity is added by deducing the returned type from the
trailing-return-type.

example from the spec:
[](int x, int y) -> int { int z = x + y;   return z + x; }
unless I am missing something here (which I might), then should someone help
me to promote/contact the ISO committee with this suggestion?

Please read my proposal below.
The lambda expression is a member function definition and is adding two
things to function definition which should not break that basic common
practice of defining functions "the C++ spirit"
1- the capture scope variables to the function
2- unnamed function name

Specifically speaking is the returned type, which is becoming *unnecessary*
complex (being deduced from the trailing-return-type) and not inline with
the way functions are defined in C++ and also adding complexity for compiler
writers as well.
since the Lambda expressions definition enforces to include the
lambda-capture braces it is just easier for the programmer to understand and
the compiler writer to program the compiler to assume the following:
1- All functions have a capture scope either implicit or explicit.
2- if it is a C like function then the capture scope is implicitly the
global variables by reference.
3- if it is a member function then the capture scope is implicitly all class
member variables by reference and all the global variable by reference.
4- if a  capture scope definition is only valid with unnamed functions and
if found for a function that has a name then the compiler will issue an
error.
5- if a function does not have any name then it can add the variables found
in the capture scope immediately enclosing braces to the scope of the global
variable by reference.
6- the compiler should deduce the best inline insert suitable to the
definition of the lambda expression

As the new standard allows to eliminate the parameters parenthesis and
return type, that will create a more loose type checking and should not be
necessary, this way the minimum lambda expression as per the standard is:
[]{} it could be looked as "cool" but it is not type safe.

my suggestion should stay more type safe, and still all the same can be
achieved by enforcing the return type and the parameters
[] void(){}


The following suggestion is more in line with the  C++ language "spirit"
where the returned value should be defined before the parameter definition
(when needed to be explicit), still the developer can use the
trailing-return-type
If the return type is complex as suggested by the new standard.

Example 1:
[] int  (int x, int y) { int z = x + y;    return z + x; } // Still Should
Be OK:explicitly defining a return value of int, no confusion with int
constructor nor with a conversion operator as a lambda-capture statment
found

Example 2:
auto x1 = [](int i){ return i; }; // OK: return type is implicitly int
[&]void (int i){ this->member_var1 + this->member_var2; } // OK no return
value.

Example 3:
[] void(int a, int b){return a+b; } // ERROR: 'void' function returning a
value

Example 4:
[] int (float a, float b) {return a+b; } // WARING  'return' : conversion
from 'float' to 'int', possible loss of data

Example 5:
[&] void () {this->a + this->b; }

Example 6:
[&] auto (){ decltype(this->m) x; return x+x;}


Looking at it from the tokenizer/parser/compiler it is easy to reach and
write the "State lambada definition started" as soon as the tokenizer
reaches the [] capture scope

Sincerely yours,

Abdulla Herzallah
CTO & Chief Software Architect of zoomio.com


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Nov 16, 2:09 am, "Abdulla Herzallah" <a...@zoomio.com> wrote:
> As the new standard allows to eliminate the parameters parenthesis and
> return type, that will create a more loose type checking and should not be
> necessary, this way the minimum lambda expression as per the standard is:
> []{} it could be looked as "cool" but it is not type safe.

How is it not type safe? I think you misunderstand what type safety
means.

> The following suggestion is more in line with the  C++ language "spirit"
> where the returned value should be defined before the parameter definition

This is a syntactic detail, not a part of the C++ language spirit. The
C++ language spirit is, according to D&E, about extensibility through
libraries and modularity of language features (the "don't pay for what
you don't use" maxim).

All in all, what are you really complaining about? That the return
type is no longer in the front? If only function declarations had
looked like lambdas from the start, C++ would be a lot easier to parse
- there wouldn't be the ambiguity between a function declaration and
an initialized object.

Sebastian


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Thanks for your reply
I can see in your mail 2 main inquiries:

> Q1- How is it not type safe?
if the deduced returned type is not the intended returned type, this will
lead to unsafe results.
according to the specification (with a very simple example if a class
convert to POD then return *this will result in the POD value returned
instead of the instance of the class (section 4 in 5.2.1) , I agree that the
rules are specified, but all this unnecessary complexity if return type is
enforced just as in functions and all this only to try to avoid the
specifying the parameters and the return type as mandatory steps in defining
the lambda

>Q2- This is a syntactic detail/"language spirit"/
Of course semantics is part of the language spirit and should stay
consistent when possible, I did not see any reason to break it that by
introduction of the lambda expression and if it is as the suggestion it will
give immediate click to the one who just learned functions and members
functions and no need to learn the exceptions if it is a lambda function,
consistency is always a key in language success and C++ has a good history
with it, why to break it,, for no reason.

[ lambda-capture] return-type ( parameter-declaration-clause )
attribute-specifier optional  mutable optional  exception-specification
optional

For sure the above it is much safer to program with well specified returned
type specially if the programmer wants the auto as return type it is still
possible.

Abdulla Herzallah
CTO & Chief Software Architect of zoomio.com


"CornedBee" <wasti.redl@gmx.net> wrote in message
news:62fe51af-8e52-4d35-819b-0777456530fa@v30g2000yqm.googlegroups.com...
> On Nov 16, 2:09 am, "Abdulla Herzallah" <a...@zoomio.com> wrote:
>> As the new standard allows to eliminate the parameters parenthesis and
>> return type, that will create a more loose type checking and should not
>> be
>> necessary, this way the minimum lambda expression as per the standard is:
>> []{} it could be looked as "cool" but it is not type safe.
>
> How is it not type safe? I think you misunderstand what type safety
> means.
>
>> The following suggestion is more in line with the  C++ language "spirit"
>> where the returned value should be defined before the parameter
>> definition
>
> This is a syntactic detail, not a part of the C++ language spirit. The
> C++ language spirit is, according to D&E, about extensibility through
> libraries and modularity of language features (the "don't pay for what
> you don't use" maxim).
>
> All in all, what are you really complaining about? That the return
> type is no longer in the front? If only function declarations had
> looked like lambdas from the start, C++ would be a lot easier to parse
> - there wouldn't be the ambiguity between a function declaration and
> an initialized object.
>
> Sebastian
>
>
> --
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]
>


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]