This is the second and final part of my C++Now 2017 trip report. You can find the first part here: "c++now 2017 trip report - part 1/2".

### thursday, may 18

I'm back home in London after C++Now 2017. Besides experimenting on personal projects and playing Hollow Knight, I think that putting together the notes I've scribbled down during the conference into a coherent article is a good use of my time. I hope you'll find some of my thoughts interesting!

### background

In case you've never heard about it before, C++Now is a gathering of C++ experts in a beautiful (and expensive!) location in Aspen, CO. In constrast to other "more mainstream" conferences like CppCon and Meeting C++, most of the content is intended for advanced and expert code wizards.

One thing I loved about this year is the theme of the keynotes: other languages. The three talks were about Rust, Haskell and D. I find it very bold to have presentations on different languages at a C++ conference, especially when they're keynotes! This shows a level of open-mindedness, courage, and desire to make C++ and its users richer by taking inspiration from others - I feel glad to be part of this community.

This post continues (ends?) the story of my attempts to create a nice "pattern matching" syntax for variant visitation.

Back in October 2016, in part 1 of the series, I discussed a simple way of implementing a visit_in_place function that would allow variants to be visited providing a set of lambda expressions that would be overloaded on the spot.

std::variant<success, failure> payload{/* ... */};
visit_in_place(payload, [](const success& x){ /* ... */ },
[](const failure& x){ /* ... */ });

Yesterday I came back from my first ever ACCU conference, ACCU 2017, which happened from April 26 to April 29 in Bristol (UK). The experience was simply fantastic - I wholeheartedly recommend attending the conference!

I reinforced my knowledge on many topics and learned new ideas by attending the high-quality talks and keynotes. The schedule was very well chosen and most of the time I found it very hard to choose which talk to see in a slot - that's a good sign about the quality of the content. Fortunately, all the talks have been professionally recorded and will be available for free on ACCU's official YouTube channel.

The "social aspect" of the conference was also very important to me. I had a chance to discuss my favorite language over a beer with very smart people that I consider friends, despite the fact we see each other only one or two times per year. I also finally met some active cpplang.slack.com users face to face and made new interesting acquaintances.

As I mentioned in my previous article many features introduced in the latest C++ standards allow functional patterns to thrive in your codebase. Two ideas from that programming paradigm that I really like are currying and partial application.

In this article we're going to:

• Introduce and briefly explain the two aforementioned concepts.

Since the advent of C++11 writing more functional code has become easier. Functional programming patterns and ideas are powerful additions to the C++ developer's huge toolbox. (I recently attended a great introductory talk on them by Phil Nash at the first London C++ Meetup - you can find an older recording here on YouTube.)

In this blog post I'll briefly cover some techniques that can be used to pass functions to other functions and show their impact on the generated assembly at the end.

(If you are familiar with lambdas and higher-order functions you can skip the following paragraphs.)

Perfect forwarding and forwarding references allow developers to write generic template functions that retain the lvalueness/rvalueness of passed arguments, in order to avoid unnecessary copies or support reference semantics without having to implement multiple overloads. (This article by Eli Bendersky explains them in depth. I will assume you're familiar with these concepts for the rest of the article.)

In this article, I'll show how to correctly capture perfectly-forwarded objects into lambdas:

• We'll take a look at an example that shows how using std::forward in lambda captures can produce unexpected results.

When writing generic code, it is sometimes useful to check whether or not a particular SFINAE-friendly expression is valid (e.g. to branch at compile-time). Let's assume that we have the following class declarations...

struct Cat
{
void meow() const { cout << "meow\n"; }
};

struct Dog
{
void bark() const { cout << "bark\n"; }
};

...and that we would like to write a template function make_noise(x) that calls x.meow() and/or x.bark() if they are well-formed expressions:

template <typename T>
void make_noise(const T& x)
{
// Pseudocode:
/*
if(x.meow() is well-formed)
{
execute x.meow();
}
else if(x.bark() is well-formed)
{
execute x.bark();
}
else
{
compile-time error
}
*/
}