Skip to content

Optional Value Boxes #690

Closed
Closed

Description

@legendecas

Napi::Value can be empty. Many of N-API will return napi_invalid_arg on empty Napi::Value as a parameter (e.g. napi_get_property). We can introduce a Maybe value box to node-addon-api to early detect these conditions and provide a clean way to indicate whether a parameter Napi::Value is optional.

Activity

  1. self-assigned this
    on Mar 26, 2020
  2. legendecas commented on Mar 26, 2020

    @legendecas
    MemberAuthor

    I'd believe this can be a better solution for #544.

  3. devsnek commented on Mar 26, 2020

    @devsnek
    Member

    Napi::Value already provides IsEmpty(). Maybe<> in the V8 API is used to represent things that throw, not things that are optional.

  4. legendecas commented on Mar 27, 2020

    @legendecas
    MemberAuthor

    Yeah, there is already an IsEmpty on Napi::Value. Still, there is no ability to provide a strong type guarantee that a Napi::SomeType is absolutely not empty, i.e. compiler will complain about the code on build time.

    If Maybe is not an appropriate name for the situation, I'm ok with another name that fits.

  5. changed the title [-]Maybe Value Boxes[/-] [+]Optional Value Boxes[/+] on Mar 27, 2020
  6. devsnek commented on Mar 27, 2020

    @devsnek
    Member

    Adding Maybe wouldn't fix the issue that there's no way to guarantee a value is not empty because the Value in the Maybe can still be empty. I do agree it would be cool if it were possible but that might be outside the bounds of the language we've chosen to work with here.

  7. legendecas commented on Apr 1, 2020

    @legendecas
    MemberAuthor

    The idea is to distinguish empty-able parameters and return values at build time.

    In the example of #544, originally we have to use a trick to achieve what we expect:

    Function callback; // this one is empty since it's not initialized with any napi_value
    auto tsfn = ThreadSafeFunction::New(env, callback, resource_name, 1, 1);

    With optional boxes, we can make Napi::Value not constructible in the way above, and use Optional::Empty instead:

    auto tsfn = ThreadSafeFunction::New(env, Napi::Optional::Empty(), resource_name, 1, 1);

    If we do have a callback value:

    Napi::Function callback = Napi::Function::New(env, some_callback);
    auto tsfn = ThreadSafeFunction::New(env, Napi::Optional::Just(callback), resource_name, 1, 1);

    Or make it implicit:

    Napi::Function callback = Napi::Function::New(env, some_callback);
    auto tsfn = ThreadSafeFunction::New(env, callback, resource_name, 1, 1);

    In this way, we can make our API stronger than just empty-able Napi::Value, with which compiler doesn't complain if it's empty where it should not be empty.

    Optional is available in stl since C++ 17, so maybe we can use stl optional directly.

  8. github-actions commented on Dec 15, 2020

    @github-actions
    Contributor

    This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

  9. github-actions commented on Jun 9, 2021

    @github-actions
    Contributor

    This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions