CppCon 2018: Andrei Alexandrescu “Expect the expected”

I really expected an expected to be inside the other expected but Andrei failed my expectations!

Update: We finally have expected in C++23!

I think a solution to expected<void, E> would be to annotate functions returning that as nodiscard, that way you would at least get a compiler warning if you just ignore the return type

edit: ok exactly that question was asked right at the end

Wouldn't returning `expected<void, error_type>` show less intention than returning `optional<error_type>`?
Since in the end both return types say 'this function might return an error or nothing'.
My guess is, that `expected<void, error_type>` would be preferred only for homogeneity among other return types.

3 years later and this still is in proposal.

Andrei is a phenomenal speaker!

Ugly shitty language

found local choreography normal (cause they do java instead of c++) LOL

"I heard you not saying", LOL.
I am going to use this quote from now on.

The guy is funny

I don't understand why they discarded the approach with storing an std::exception_ptr instead of some template argument E inside the Expected. If I remember correctly, that's what Andrei initially proposed a few years ago when presenting the idea of Expected. That approach looked much cleaner (no need to specify two template arguments) and more flexible (you could store any kinds of exceptions in the Expected, even if the function "throws" multiple unrelated exception types).
Is there an explanation why this decision was made now?

Slide 28: it might be better to use std::conjunction to short-circuit the expression inside enable_if.
Also, another part of homework for implementers: make this swap() function conditionally noexcept, where it can be. That could help some other generic code to be more efficient.

He's absolutely right about how expected should behave, down to the last detail. I really hope the standards committee makes it and does it the way he recommends, right down to not having operator *.

I've been thinking through how to do error handling for a hypothetical C++ wrapper to the POSIX/Linux api. I came to the exact same conclusion for how it should be done.

Compilers are good enough at flow analysis to emit diagnostics if you never check things like `expected<void>`, or even if you ignore any exected.

If you write your application using expected with exception handling deactivated, then .value() is surly also undefined behavior?

I love the way he presents! Very conversational, and natural, while still hitting all the salient details and not just outright repeating whats on the slides. And funny, throwing in jokes - not nervous at all. He also anticipates our possible thinking stumbling blocks and even addresses the natural tangential side-thoughts. Totally comprehensive. And from a non-native speaker of English, it's all the more impressive. What a legend! (much better than Titus - total opposite in fact) - almost on Bjarne's level. Big fan of his contributions too. He really sees the big picture and doesn't get distracted.

1. Great and entertaining talk.
2. There's a ')' missing in slide 30, I think.

it is mimicking the NAN convention in floating point computation.

yet another way to handle errors in cpp?

I finally decided that Andrei's voice reminds me of Triumph the insult comic dog. "This code is really great... for me to poop on!"

where is monadic bind operator?

Around ~ minute 4 it was clear that this will sound like C++'s version of Rust's "Result<T, E>".

Can someone explain, why did they use placement new instead of simple initializing in constructors?