When we added the equivalent to Rust, it was a bit controversial. But the idea of "an optional type is a list with zero or one items in it" is much more normal in functional places, and so a lot of people like it quite a bit too.

I really like how some good structures used by other languages, specially Rust and Zig, have been added to the newer C++ standard.

The Result, Optional, and Variant are really sweet for day-to-day use of the language, and those in-process standard libraries of SIMD operations, BLAS mathematical functions, and the the execution library looks really cool, specially as standard.

I would like C++ would be a little more "batteries included" in some ways, like having a basic standard for signals, networking (just handling sockets would be a huge thing), and some basic system calls.

Herb Sutter calls this kind of thing "spelling things generically" meaning that the same generic code will compile against different types. In this case the same for loop code will compile against a type that may hold zero or one items and a type that may contain 0->n items. Maybe this pattern could be extended to shared_ptr for example.

It's sort of like a cleaner approach to a C# SelectMany where you return either an empty array or a single-item array?

C++ keeps getting more stuff but it's clear a lot of thought goes into these additions. I think a "living" language has proven better over time (C# evolved heavily and borrowed from other languages, C++ does as well, maybe lately concepts from functional and Rust?) Go might be the big exception that evolves super-slowly.

The for syntax over optional seems unnatural. I get that optional is like a list of 0 or 1 owns. Is there a fault in my reading that makes the syntax clunky?

Seems like a good thing broadly. I haven't personally found a use for ranges, ever, but this seems consistent.

Maybe somewhere in C++60 we will finally have proper monads

Great to see they learned from Java, which initially made the mistake of not supporting the streams interface for their Optional type at first [1]. It was infuriating.

[1] https://stackoverflow.com/questions/22725537/using-java-8s-o...

The example program seems confusing and pointless. Who uses the bell for debug logging? I found it distracted from the central point of the article as I stared at this bizarre program.

> the people writing the standard are not exactly known for adding features “just because”

Ah yes, C++, the discerning language.

Iterating over optional does seem syntactically convenient. My main question would be if it guarantees no overhead. For example, is there an additional conditional branch due to the iterator hiding the statically know fact that there's at most one iteration? I don't use C++ for its beauty, I use it for speed.

I do enjoy seeing C++ pick up these features from other languages.

... it's unfortunate that the feature then ends up in C++ syntax, which is increasingly divorced from the way it's used today, the kind of thing that nobody would have written from scratch if they were starting day-1 with these ideas in play. I look forward to having the features, but not to having to read things like `const auto flt = [&](int i) -> std::optional<int>` or `for (auto i : std::views::iota(1, 10) | std::views::transform(flt))`.

This is absolutely magnificent. Game-changing improvement, really shows how amazing the C++ committees are working.