Serial Communication Library VS outcome

Ultimately, I plan on using a serial library to talk to the port myself because I need to intercept what is typed into the terminal and build a packet out of it, but even then I don't know if the bottleneck will still be present and if the serial library even supports up to those speeds. I am familiar with wjwwood serial but can't find any information in its limits. I see a few commits for 500 kbps support but I don't know if that's its limit.

I’m not sure what you want. Everything exists in posix and win32. Maybe you want something like that? https://github.com/wjwwood/serial

https://github.com/ned14/outcome/tree/develop/abi-compliance uses both in a CI pass to ensure Outcome never changes anything which breaks either API or ABI with earlier versions.

outcome and/or expected

A "Sample Usage" appears on the front page of the docs: https://ned14.github.io/outcome/

I recently came across boost outcome as I was searching for a better error handling method. It took me a minute to get a hang of it but now I love it. After creating my own policy and a few aliases for easier use.

std::optional and std::variant can be a bit awkward to use in this scenario, though. Consider a dedicated type like boost::outcome (standalone versions) or one of the implementations of the proposed std::expected.

Minimum possible compile time impact is a key goal of https://github.com/ned14/outcome. We ship a single header edition which only includes the low impact standard headers as listed at https://github.com/ned14/stl-header-heft. We also don't use union storage for non-TC non-MB types in order to avoid complex metaprogramming execution by the compiler per instantiation.

It's really weird that I wrote the above, and then this bug was reported to Outcome: https://github.com/ned14/outcome/issues/244. Here is my exact complaint about lack of lifetime tracking in C++.