CppCon 2015: Michał Dominiak “Applying functional programming in code design'

—
—
At first glance C++ doesn't seem to be a language that lets you do much functional programming, not to mention actually focusing the structure of your application around that. But that is changing, together with the general approach to program in the language. We do care about const-correctness; when writing code meant to run concurrently, we want to avoid locks, so we do our best not to share mutable state (I'm here to argue that uniquely owned mutable state is perfectly fine). With that mindset, we can try to design our applications in a functional way.

This talk will focus not only on things typically associated with functional programming, but also on the following in the context of C++: * Making functions pure (as long as it makes sense). * Using functional data structures. * Designing control flows that don't lead to shared state. * Composability and benefiting from laziness. * Striving for generic code. * Noticing patterns and turning them into abstractions. * Functors and monads as "patterns". * An example application built around those principles.
—
Computer Science student at Faculty of Electronics at Wrocław University of Technology. Loves metaprogramming and doing as much as possible during compile time, instead of wasting precious cycles at runtime.
—

*-----*
*--*
*-----*

[sutambe]

Slide #17 I think passing two lambdas--one for success and one for exception--to future.then would be quite unpleasant because when both lambdas need the same captured state, they have to either make a copy of the state, which may not make sense at all or more commonly, dynamically allocate state and share a pointer to it (via shared_pointer). Both approaches have performance downsides. I like .then continuation accepting future even if it does not match the functor/monad intuition.

[matias]

Maybe you can be interested in n4017 or N4048 More Improvements to std::future

It was rejected unfortunately, only some minor thing were retained.

P0058R0 proposes also a continuation interface that request the value instead of the future.

[matias]

Yes, having the future as parameter has its advantages. IMO, future continuations should accept expected T as parameter as a future T ready is homomorphic to expected T. When the execution of the continuations are syncrhonous, on the same thread, you can have two continuations that refrence the same state.
Sorry I have tried to write the code but no way due to HTML ..

then :: (future T) ( (expected T) -> ( match:: (T -> R) (exception_ptr -> R) )

[Griwes]

This is indeed a valid comment; I do not have an answer for this case *yet*, although I think that a functionality for this case should be separate from the "main" one. Alternatively, you could have `.then` overloaded: one taking functions that take T as an argument, and the other taking future of T, but I'll have to think about it. Thanks!

[YourCRTube]

20 pages of text with ~6 lines of code total, none of which an actual application of the concepts. The topics are also not numbered or partitioned in any way - one slide is a detail, after that there is an introduction of a concept, then an observation, then advice/guideline. The talk lacks structure and examples. Also it is either "an introduction" or "guidelines", the latter assumes prior experience.