As someone who is dealing with modern C++ (whatever happens since C++11), There is a good chance that we probably met std::optional<T>. It’s that well-behaved feature from C++17 that says:

"Here’s a box. Sometimes it has a T inside, but sometimes it’s empty. Deal with it."

That's very tidy, very predictable like packing my own lunchbox. Either there’s a sandwich inside, or it’s nothing but hunger. Then along comes C++26 with std::optional<T&>. Instead of packing its own lunch, it just leaves a Post-it note saying:

"Sandwich is over there in Mohamed's fridge, provided it’s still there and hasn’t gone bad."

So what’s the difference? Let’s break it down:

• std::optional<T> (C++17)

  • Stores and owns the value.
  • Safe and predictable copy/move semantics.
  • Lifetime fully under control.
  • Think: Our own neatly packed sandwich in a box.

• std::optional<T&> (C++26)

  • Holds a reference, never owns the value.
  • Lifetime safety relies on the referenced object.
  • Copy semantics are effectively just aliasing.
  • Think: a note pointing at someone else’s fridge.

But why this new feature? Because sometimes you want to express "maybe a reference" without the overhead of copying or moving the object. It’s useful in scenarios where you want to avoid unnecessary copies, especially for large objects, or when you want to refer to an object that is managed elsewhere. The new optional<T&> makes it easier to express "maybe a reference" without hacks like std::optional<std::reference_wrapper<T>>. It introduces convenience where before you had to bend the design a bit.

So in summary:

• C++17 gave us the reliable lunchbox, that is std::optional<T>.
• C++26 adds the convenience of the Post-it system useful, but we’d better hope the fridge owner hasn’t walked away with our meal. This is std::optional<T&>.