Skip to content
New issue

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

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

Already on GitHub? # 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

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

No branches or pull requests

1 participant