TODO: Proposed API & Packaging Improvements (+ Planned Breaking Changes)
lamarrr opened this issue · 4 comments
- 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
andResult
‘svalue
anderror
methods conform to the C++ object model and use references. - Document exception guarantees
-
Some
,Ok
, andErr
are value forwarders, hence, they shouldn’t have any other method or operations whatsoever, even copy. - Make the methods external to
Result
andOption
and support const references, l-value references, and r-value references. - Separate
Option
andResult
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
andResult
actually usestd::invoke
- reduce and streamline methods in
Option
andResult
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
andFixedReport
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
andResult
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
andTRY_SOME
and replace withSTX_TRY
? - rename
CFG
toSTX_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
Hello,
[TOP PRIORITY] add specialization for Result<void, Error>
is marked as done, is this already in the repo somewhere ?
Thanks in advance.
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
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.
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>();
}