expected

C++11/14/17 std::expected with functional-style extensions

Explore on GitHub Read Hacker News discussions

5Distinct people

5Mentions

0Explicit recommenders

1.9KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

C++11/14/17 std::expected with functional-style extensions

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year5 dated mentions

Observed mentions: 2019-01-17 11:40:34 UTC to 2023-08-14 04:31:03 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	0	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	0	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	0	1

What Hacker News says

5 sources

naruhodo·Aug 14, 2023

I quite like the option of being able to program in a more functional style in C++. If you have the cycles to spare, or a sufficiently smart compiler and it allows you to say more with fewer keystrokes and better readability then why not? I haven't used it yet, but C++ Streams[1] is a header-only library that appears to have great ergonomics and an API that will feel familiar for those who know Java Streams. Since I haven't had the luxury of being able to use C++20 yet, I was unfamiliar with the ranges library. Starting at 1:06:00 you can see some motivating examples for those and they look great to me. Much easier to read than the equivalent STL. The libraries mentioned in the video TartanLlama/optional[2] and TartanLlama/expected[3] clearly demonstrate the value proposition (brevity and clarity) on their github pages. [1] http://jschein

Read the rest

y.github.io/Streams/ [2] https://github.com/TartanLlama/optional [3] https://github.com/TartanLlama/expected

In Functional Programming in Modern C++: The Imperatives Must Go [video]

jgavris·Aug 13, 2022

Eventually you'll be able to use std::expected in C++23! https://en.cppreference.com/w/cpp/header/expected Don't throw exceptions, require the caller to handle errors and propagate them up the stack (everything returns an expected) if they cannot be handled. You are forced to model the error domains instead of just throwing an exception and assuming the caller knows to catch it and do something with it. Java has checked exceptions, but, Kotlin decided to abandon them. The nice codebases I have worked on stick to the Result<T,E> type in Swift or Kotlin. And thus you are forced to 'translate' errors (exceptions?) as described in Alan Griffith's 'Exceptional Java'. https://accu.org/journals/overload/10/48/griffiths_406/ "If a checked exception is thrown (to indicate an operation failure) by a method in one package it is not to be propagated

Read the rest

by a calling method in a second package. Instead the exception is caught and "translated". Translation converts the exception into: an appropriate return status for the method, a checked exception appropriate to the calling package or an unchecked exception recognised by the system. (Translation to another exception type frequently involves "wrapping".)" If you can't wait for C++23, there's a single header implementation here. https://github.com/TartanLlama/expected

In Why should I have written ZeroMQ in C, not C++ (2012)

AaronFriel·Jun 16, 2020

There are two things being discussed in this thread. 1. The first, my original point was that a high quality type system enforces correctness by more than just having generics. There's no proper way in C++ to create this class and make a sum type - there's no pattern matching or type narrowing like can be done in languages with more interesting type systems and language facilities. Generics is just a first step to a much more interesting, safer way of writing code. 2. The second, my replies to folks who have corrected me, and I'll borrow your little paraphrase here: > [Me]: "C++, Java, and so on have had generics for ages and with types like the one above, null pointer exceptions are incredibly common." > > jcelerier: "you'd never get a null-pointer exception in C++ given the type that OP mentioned." > > [Me]: "Then you can't construct it

Read the rest

unless it's successful, no?" I think this is exactly correct still. If it's impossible to create an instance of Result<T> without... well, a successful result, you may as well just typedef Result<T> to T, right? If it can't store the "failure" case, it's totally uninteresting. If it _can_ store the failure case, making it safe in C++ is fairly challenging and I dare say it will be a little longer and a little less safe than a Result I can write in a few lines of TypeScript, Scala, Rust, an ML or Haskell derivative, and so on. Now, I'd love to be proven wrong, I haven't written C++ for a while so the standard may have changed, but is there a way to write a proper enum and pattern match on the value? It looks like this std::expected thing is neat, but can a _regular person_ write it in their own code and expect it to be safe? I can say with certainty that I can do that for the languages I listed above and in fewer than 10 lines of code. The C++ answer to that is, well, this: https://github.com/TartanLlama/expected/blob/master/include/... I don't think it's a comparison.

In The Next Step for Generics

grandmczeb·Jun 16, 2020

Yes you can? The equivalent type in C++ is std::expected[1] which doesn't even contain a pointer that could be dereferenced (unless T is a pointer obviously). [1] unfortunately not standardized yet https://github.com/TartanLlama/expected

In The Next Step for Generics

starbugs·Jan 17, 2019Submission

C++11/14/17 std::expected with functional-style extensions

1 points · Open discussion