Functional C++ - Gašper Ažman - C++Now 2024

[@AntonioBarba_TheKaneB]

I've been coding professionally in C++ since 2008... I understood MAYBE 10% of the talk... MAYBE! I really need to get up and study a bunch of the new things, C++ has really become 3 languages in one in the last decade or so :|

[@Voy2378]

function signatures are hard to read if you do not know how to read them , but I think he explains quite well in his get host example how optional and member function on it make it easier to read the code....

[@Evan490BC]

I _think_ I understand a large chunk of C++, up to C++23, but not this part. Of course this is state-of-the-art code, but the complexity of the language is getting out of hand...

[@Roibarkan]

46:54 [14.2] I think the bug that Hana refers to is that the slide has: ‘9’ = src[0]. As a side note cpp2 (a.k.a cppfront), like python, allows things like ‘0’

[@pmcgee003]

Correct. In two places. Good reason to write it as ('0'

[@Roibarkan]

12:28 Tony’s “Complecting made Easy”: kzbin.info/www/bejne/oISsfq2fp7F9gac

[@zxxvcc]

"The talk runs through the basic elements of functional programming, why we want to do it, and some compositional patterns." IMO it would be good to not obfuscate the "basic introduction" with lots of jargon that only people who already understand the topic know about.

[@Roibarkan]

27:41 [10.9] I don’t understand why line 14 needs the auto keyword (I think a c++23 feature that forces a temporary to be created).

[@AlfredoCorrea]

given the way value_or is defined, the program will create a copy one way or another. I think the only questionable advantage of using `auto(…)` is that the copy is explicit.

[@denisfedotov6954]

I believe, auto(t) is just a more concise way to write std::remove_cvref_t{t}.

[@N....]

29:55 clever! I'll have to remember that trick

[@jurgenreiss3264]

Are the pack elements evaluated lazy? Lets say we have a pack (a & b) where a and b are monadic computations. If a is "nothing", will b calculated at all? Much in the spirit of an applicative?

[@GasperAzman]

C++ doesn't give you that support in-syntax, so they aren't lazy. The library is planning support for something like (a & lazy([]{return b;}) that /would/ be understood to be lazily evaluable and eval `b` once the pack ctor gets to it.

[@JhraumG]

sum is actually a sum type, so the name sounds OK. otoa I feel that pack could be a tuple, would the qualitiy of life flattenings exposed here be transposed to tuple ?

[@dreamiix3172]

Functional pattern maybe able to make coding more convenient, but what is about performance affectness? Are these patterns well optimized by the compiler, what differences between generated code we have in any cases? General speaking, laziness is the opposite of performance, functional code harder to debug and often it does not give clear view of computational complexity.

[@friedrichdergroe9664]

C++ is cool, but I think your use case would be better off in Haskell.

[@Evan490BC]

Yeah, I was thinking the same, but he works in the financial sector, where C++ is one of the main languages used. I know that people have used Haskell to model financial contracts but some companies do not accept Haskell as an option because of the difficulty in hiring proficient people.

[@toddfulton2280]

"The type system is a proof system" Someone actually understands. 😊