Quantcast
Channel: ReScript Forum - Latest posts
Viewing all articles
Browse latest Browse all 2592

Proposing new syntax for zero-cost unwrapping options/results

$
0
0

This would be nice addition to ReScript! :heart:

Probably I’m late to the party, but here’s the shower thought. The proposed syntax is a little bit inconsistent with promises if we look at promises, options, and results as some kind of boxes/wrappers/monadish-things that either resolve to a “good” or “bad” value. Both let? and await are basically shortcuts to express:

  • Unbox the value and if it’s good, assign and go on;
  • otherwise return the bad value putting it in the box again

In the case of promises the syntax looks like this:

let variable = <unboxing_designator> <expression>

whereas in the case of options and results it has the designator in another position:

let<unboxing_designator> variable = <expression>

With further comparison, the await is more versatile in the sense it evaluates to expression, not a statement, so the following is possible:

let something = foo(await bar(), await baz())

With everything mentioned in this thread I understand that the current implementation requires that the designator should be somewhere very close to let, but I wonder if such asymmetry is fine in the long run.

Just thinking aloud: what if unwrapping be more like await?

let bar: unit => result<string, [#errA | #errB]>
let baz: unit => result<string, [#errA | #errC]>
let foo: (string, string) => string

let myFunc = (): result<string, [#errA | #errB | #errC]> => {
  let something = foo(open bar(), open baz())  // <- reusing `open` keyword, might be `try` if not followed by `{`
  something
}

Viewing all articles
Browse latest Browse all 2592

Trending Articles