napi-rs/napi
Daniel Henry-Mantilla 0204ef9342 Added a way to opt out of error handling for ThreadsafeFunctions.
This is to allow having the `ThreadSafeFunction` expect the same calling API
as an unwrapped `JsFunction` would have: in some contexts this consistency is
more desireable than giving the option to the caller to handle a native-to-js
conversion failure (or somebody having directly fed a `Result<T>`; although
that use case seems oddly niche to me: it can already be covered when
`type T = Result<U>;` and propagated/flattened inside the `R` closure with a
simple `?`), since such failure can already be quite fatal / unexpected in
some cases.

In order to keep the code backwards-compatible, this PR uses an added
**optional** generic (type) parameter. Since this parameter, semantically,
represents an `enum`, and since we don't have yet `const_generic` `enum`s, we
circumvent this limitation by using the type-level enum pattern, which is
abtracted away with a helper macro that incidentally yields some handy docs
(I can attach a rendered version of the docs hosted on netlify if the reviewer
so wishes).
2021-03-09 23:51:12 +01:00
..
src Added a way to opt out of error handling for ThreadsafeFunctions. 2021-03-09 23:51:12 +01:00
Cargo.toml napi@1.2.0 2021-02-26 18:52:31 +08:00