@c_discussions

Why there is no syntactic sugar for such thing? I can't imagine having

`std::expected<std::vector<std::string>, ErrorCode>

in my APIs 🤯 And why I need to wait for having this feature in C++23, if I can use std::variant or std::pair 😂

BTW std::expected seems like from some testing framework... Result<R,C> or StatusReply<R,C> are way better names for this.

Follow

@rttf @c_discussions

A better starting point is std::optional. Look at my post in response to the OP, which has a link to an article I did on this before std::expected.

I'd do the simplification of your question as:

```
using StringVec = td::vector<std::string>;

std::expected<StringVec, ErrorCode>
```

@rmerriam @c_discussions

Yeah, I use std::optional a lot, but the problem is that it doesn't convey information about error code. std::expected does, but as everything in #cpp world... it's very verbose. I'm aware that usage of `using` can improve readability, but my point is that such feature should have a syntactic sugar support ( something like parameter packs for instance), because for libraries compiled w/o -fexceptions it would be used heavily across the whole codebase.

Sign in to participate in the conversation
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.