lamarrr/STX

TODO: Proposed API & Packaging Improvements (+ Planned Breaking Changes)

lamarrr opened this issue · 4 comments

lamarrr commented
  • rename and separate config.h into stx_cfg_utils as users might think they need to modify the config header file to use STX
  • Make Option and Result‘s value and error methods conform to the C++ object model and use references.
  • Document exception guarantees
  • Some, Ok, and Err are value forwarders, hence, they shouldn’t have any other method or operations whatsoever, even copy.
  • Make the methods external to Result and Option and support const references, l-value references, and r-value references.
  • Separate Option and Result and use helper functions to resolve the tight dependencies. (stx_option, stx_result). This would also enable us to use SFINAE to dispatch methods where necessary without too much code.
  • Separate panic features into separate stx_panic package, there should be no dependency on non-STX packages by default.
  • Evaluate if panic could benefit from branch guiding i.e. [[unlikely]]
  • Report should also be under the panic package
  • Separate panic implementations (stx_panic_halt, stx_panic_abort, etc.)
  • add stx_panic_pretty_stacktraced package
  • Make panic always use an injectable function pointer (hooks) since it’s always in the cold path and panics should only happen once before permanent termination.
  • Let the user customize panic behavior at runtime only and not via cmake config which is already confusing.
  • Make Option and Result actually use std::invoke
  • reduce and streamline methods in Option and Result to make it easier to maintain and extend (i.e. redundant methods like most Option::*).
  • [TOP PRIORITY] add specialization for Result<void, Error>
  • Replace mutexes with a custom hybrid spin lock implementation as embedded systems don’t support it
  • Consider using fmt or fmt-style interface for panics. It should be allowed to use dynamic memory
  • Remove static methods in Span and make them helper functions instead.
  • Replace SpanReport and FixedReport with better and safe alternatives, consider:
  • add default reporters for enum types. By just casting to the enum’s underlying type. I’ve found it quite tedious implementing reporters for each enum type for each API I’m using. Sometimes I’m satisfied with integers.
  • let Option and Result be constexpr for constexprable trivial types
  • Explore other light-weight and portable alternatives to absl’s backtrace which is quite heavy and slows down our build at the moment
  • Remove all noexcept statements and defaulted constructors and operators (See: #31)
  • Move option and result comparison operations outside of the structures and to a separate header
  • Verify and add tests for panic hooks if possible
  • Simplify and rewrite CMake File
  • Change documentation solution
  • Draft tutorials
  • Clean up and publish the internally developed async and task library (could help @Invander29 #9)
  • Publish the remaining internally used utilities (enums, struct, limits, etc).
  • Logo and brand change
  • Remove coroutine macros
  • SFINAE macros + header
  • Option and Result SFINAE support? I’m not convinced this is important
  • Allow projects to inject namespaces or symbol overrides (I.e. where there are multiple or same STX versions packaged differently).
  • stx_mem stx_res stx_limits stx_enum
  • Add clang format file + CI check (#27)
  • Add more ARM and embedded systems CI tests
  • remove libatomic auto linking find_library(LibAtomic atomic)
  • remove TRY_OK and TRY_SOME and replace with STX_TRY?
  • rename CFG to STX_CFG?
  • a number of const& are unnecessary since the types are cheap to copy
  • add CI examples building
  • add CI clang format checks
  • consider making Result and Option's destructive methods (I.e. Methods that move out the value) allow l-value references
athanase commented

Hello,

[TOP PRIORITY] add specialization for Result<void, Error>

is marked as done, is this already in the repo somewhere ?

Thanks in advance.

lamarrr commented

Hello,

[TOP PRIORITY] add specialization for Result<void, Error>

is marked as done, is this already in the repo somewhere ?

Thanks in advance.

Hi, it was up for consideration but I decided not to implement it because it would lead to a lot of code repetition and high maintenance burden for little gain

athanase commented

I understand. There is currently no way in STX to write the following snippet other that specializing Result<void, Error>, right?

stx::Result<Error> foo::bar()
{
    if( failing )
    {
        return stx::Err( Error::some_error );
    }
    return stx::Ok();
}

I am asking this because when using STX's approach to error handling I think it is a good thing to use it for this specific use case as well.

lamarrr commented

Sadly, yeah. There is no way to do that.

You can define a regular void type and do:

struct Void{};

stx::Result<Void, Error> foo::bar()
{
    if( failing )
    {
        return stx::Err( Error::some_error );
    }
    return stx::Ok<Void>();
}
  • 👍1