Date: Sat, 7 Jun 2025 13:26:32 +0200
Sounds like: https://github.com/mpusz/opt
// Robin
On Sat, Jun 7, 2025, 13:24 Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I don't think it's worth the effort if it cannot work for fundamental
> types, and the ABI for std::optional is set in stone. Ideally, we
> would be able to say that std::optional<X*> where nullptr stores the
> empty value, or std::optional<int> where -1 represents an empty value,
> etc.
>
> Those things seem feasible with std::expected with a bit of library
> support. We could have something like
>
> > std::expected<int, std::nonvalue<-1>>
>
> Which would use the value "-1" to represent an unexpected object. This
> would also not break any existing code since it would use novel types
> and a novel protocol, even in the case of fundamental types.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
// Robin
On Sat, Jun 7, 2025, 13:24 Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> I don't think it's worth the effort if it cannot work for fundamental
> types, and the ABI for std::optional is set in stone. Ideally, we
> would be able to say that std::optional<X*> where nullptr stores the
> empty value, or std::optional<int> where -1 represents an empty value,
> etc.
>
> Those things seem feasible with std::expected with a bit of library
> support. We could have something like
>
> > std::expected<int, std::nonvalue<-1>>
>
> Which would use the value "-1" to represent an unexpected object. This
> would also not break any existing code since it would use novel types
> and a novel protocol, even in the case of fundamental types.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2025-06-07 11:26:48