CppCon 2018: Andrei Alexandrescu “Expect the expected”

—
—
Writing code that is resilient upon errors has always been a pain point in all languages. Exceptions are the politically correct means to signal errors in C++, but many applications still resort to error codes for reasons related to ease of understanding, ease of handling errors locally, and efficiency of generated code.

This talk shows how a variety of theoretical and practical artifacts can be combined together to address error codes and exceptions in one wholesome, simple package. The generic type expected＜T＞ can be used for both local (error-code-style) and centralized (exception-style) manners, drawing from the strengths of each.
—

Andrei Alexandrescu, The D Language Foundation
Vice President

Andrei Alexandrescu is a researcher, software engineer, and author. He wrote three best-selling books on programming (Modern C++ Design, C++ Coding Standards, and The D Programming Language) and numerous articles and papers on wide-ranging topics from programming to language design to Machine Learning to Natural Language Processing. Andrei holds a PhD in Computer Science from the University of Washington and a BSc in Electrical Engineering from University "Politehnica" Bucharest. He is the Vice President of the D Language Foundation.
—

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

[mrlithium]

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.

[acf]

3 years later and this still is in proposal.

[ovndfbs]

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

[belst_]

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

[Omnifarious]

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.

[aliancemd]

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

[WiktorWandachowicz]

Big possible change at 33:55 wrt. exceptions - and at 34:00 I even did the clapping myself :)
To create exceptions and use them for handling errors, *without* throwing the exceptions immediately is IMHO a really great idea! Such a simple solution: a function should return a real value or exception object. Simple, powerful, beautiful. Go, JF!

[masondeross]

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

[eLBehmo]

At 50:00: For those who want the returned and unchecked error to throw (in the destructor of expected): yes I implemented such a solution and 'it works'. But you generally don't need it if you mark your functions nodiscard and check your warnings!

[OperationDarkside]

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

[timseguine]

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!"

[RaaynML]

22:50 does anyone have a link to the function by Herb Sutter mentioned?

[zhaoli]

it is mimicking the NAN convention in floating point computation.

[wintermute]

34:45 Is there any difference between calling the copy constructor with placement new vs. using a member initialization list, i.e. : yay(rhs) ?

[oof-software]

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.

[blenderpanzi]

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

[erikvanvelzen]

37:55 I'm not 100% sold on the constructor-based thing. Personally I would have a private constructor with named constructors std::expected::ofValue and std::expected::ofError. Though I see that's a bit more verbose.

edit: I see at 47:50 something like that exists, so you can use either expected() or unexpected()

[MaceUA]

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?

[Mirality]

47:56 I wonder if the missing parenthesis was unexpected...

[vvviiimmm]

So if anyone familiar with IO[A, E] or even Either[A, B] types in FP -- this is essentially the same with a lot of C++ noise. Furthermore, the proposed implementation doesn't compose well (52:12)