Date: Sat, 07 Jun 2025 20:12:23 +0300
Why wouldn't it work with fundamental types? I explicitly marked them
as supporting the protocol. Maybe I did a bad job of explaining myself.
And again some raises std::expected, it's not related. This is for
every container that can conditionally carry a value, std::optional is
the best example but I encountered the problem while working on a
different class (an interval type).
On Sat, 2025-06-07 at 13:24 +0200, Jan Schultke 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.
as supporting the protocol. Maybe I did a bad job of explaining myself.
And again some raises std::expected, it's not related. This is for
every container that can conditionally carry a value, std::optional is
the best example but I encountered the problem while working on a
different class (an interval type).
On Sat, 2025-06-07 at 13:24 +0200, Jan Schultke 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.
Received on 2025-06-07 17:12:27