Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolutions of Lambdas in C++14, C++17 and C++20

fluentcpp.com

Post reply on HN
Print view View original

11–20 of 75 posts

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#11

Post by ncmncm »

mgaunard wrote: post #6

Template lambdas is in my opinion the most useful evolution and has been a long time coming. I figure it was held back by template haters who want terse syntax and don't understand how it's much more powerful than auto/concepts. I wouldn't say it's a smaller evolution than previous iterations.

Agreed. C++11 was a major evolutionary step for the language, but C++14 made it fun, too. C++20 is as large a step as C++11, but it will take as long for people to absorb. C++23 will bring usability improvements for async/await and maturity to library ranges.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#12

Post by CraigJPerry »

rich_sasha wrote: post #10
gpderetta wrote: post #8

Earlier quoted context omitted.

In this case x must obviously be in a new scope as all function parameters. There isn't possibly be an ambiguity here.

I think grandparent is referring to myLambda - that could be a new variable or overwriting of an existing one. I agree with them, in Python the number of times something like this happens: myVariable = 10 myVariablr = clever_function(myVariable) (note the typo in variable name)

>> in Python the number of times something like this happens

Anec-data but I’ve been writing python for 15+ years, I’ve contributed to various popular open source projects. I’ve never seen this in a code review. I’ve certainly never seen this kind of mistake released.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#13

Post by ncmncm »

pjmlp wrote: post #7
bruce343434 wrote: post #3

Earlier quoted context omitted.

syntactical disambiguation, there's already something called "the most vexing parse". C++ is full of little holes like these and getting rid of auto would surely at least double compile times or at worst make parsing C++ actually impossible.

That is what happens when a language makes the compromise to be copy-paste compatible with https://cdecl.org/

More to the point, it means the language continues to interpret header files from C libraries the same way that the C compiler always has.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#15

Post by gpderetta »

rich_sasha wrote: post #10
gpderetta wrote: post #8

Earlier quoted context omitted.

In this case x must obviously be in a new scope as all function parameters. There isn't possibly be an ambiguity here.

I think grandparent is referring to myLambda - that could be a new variable or overwriting of an existing one. I agree with them, in Python the number of times something like this happens: myVariable = 10 myVariablr = clever_function(myVariable) (note the typo in variable name)

Oh I didn't even realize that OP had removed auto from myVariable. Of course I strongly agree that auto or some other syntactic marker is needed there!

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#16

Post by mhogomchungu »

gpderetta wrote: post #9

Regarding returning lambdas, of course it could be done even in c++11 via std::function.

Problems with std::function:-

1. It can not hold move only callable objects.

2. It heap allocate stored callable object if the object is large enough.

Re: The Evolutions of Lambdas in C++14, C++17 and C++20

#17

Post by nly »

mhogomchungu wrote: post #16
gpderetta wrote: post #9

Regarding returning lambdas, of course it could be done even in c++11 via std::function.

Problems with std::function:- 1. It can not hold move only callable objects. 2. It heap allocate stored callable object if the object is large enough.

3. Type-erased (its primary use case, but hinders optimization)

4. Can't be constexpr

Post reply on HN