Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

O.Option's functions with null literal value behaves differ from with undefined literal values #97

Open
JUSTIVE opened this issue Dec 28, 2023 · 1 comment

Comments

@JUSTIVE
Copy link

JUSTIVE commented Dec 28, 2023

From the type definition of O.Option<A> = A|null|undefined, where A is regarded as Some<A>, and null | undefined as None, I thought that literal null values should behave the same as undefined literal values.

I've just written some examples from ts-belt's live editor.

nullish values O.match O.isNone
null image image
undefined image image

for example, the O.match is described as follows, where the null value could passed into someFn.

function _match(option, someFn, noneFn) {
  if (option !== undefined) {
    return someFn(Caml_option.valFromOption(option));
  } else {
    return noneFn(undefined);
  }
}

and O.isNone seems generated from the gentype utility from the rescript-compiler.

I found that O.fromNullable for every null occurring situation, but it's very cumbersome, and so unintuitive because of O.Option's type mismatches with these behaviors.

@JUSTIVE
Copy link
Author

JUSTIVE commented Jan 26, 2024

related to #85

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant