Explore if-let syntax more?

[cristianoc]

Does it make sense to explore the if-let syntax more seriously?

Here's some imaginary example where several different language features could be handled at the same time:
https://github.com/cristianoc/rescript-compiler-experiments/pull/1/files#diff-81c7d8224cb32d4696c8931f3c4fa65fd0e1a0b036e6fe9b4fffd730d86d3412R176

Basic, non-nested version, discussed here: https://forum.rescript-lang.org/t/are-if-let-constructs-going-to-be-supported/3373

Precedent for a more advanced version: rust-lang/rust#94927 (comment)

[cristianoc]

CC @IwanKaramazow

[IwanKaramazow]

The main use case would be the async chain?

[cristianoc]

The main use case is to address user requests from the past.

There was a time when the community was quite vocal in asking for monadic let support. This covers roughly the same application area (without runtime artefacts for e.g. optionals etc that the compiler currently can't eliminate).

Judging from the forum https://forum.rescript-lang.org/t/is-it-a-good-idea-to-explore-if-let-more-seriously/3698, initial comments seem to indicate that the community does not have pain points in this area at the moment.

So there seems to be no basis for investigating syntax extensions for the time being.

[fhammerschmidt]

The same goes for async/await. The existing members are already used to Promises or their favorite promise library.

However if if let helps making async/await more useful, it may help to draw in more users or even move people away from promises.

[cristianoc]

However if if let helps making async/await more useful, it may help to draw in more users or even move people away from promises.

One would need good confidence in that assumption before investing resources. How could one test the hypothesis that it would help new users?

[cristianoc]

For example, in the case of async/await, it has been reported all the time that not having it is an obstacle to onboarding new team members / getting adoption inside a company. So that case is pretty clear.

[cristianoc]

Perhaps it makes sense to consider taking a smaller, idiomatic step, and explore how optional chaining https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html would fit in the language, how well it would go with records which have optional fields.

[cristianoc]

From what I can see e?.f is simply an abbreviation for

switch e {
| None => None
| Some(x) => Some(x.f)
}

and e?.f?.g by composition

switch {
  switch e {
  | None => None
  | Some(x) => Some(x.f)
  }
} {
| None => None
| Some(x) => Some(x.g)
}

[cristianoc]

Actually not sure what should happen when f has optional type, the old problem of nested optionals.

[cknitt]

For me the issue with something like

 if let Ok(response1) = await FetchResult.fetch("https://www.google.com")
    and Some(url) = nextFetch(response1)
    and Ok(response2) = await FetchResult.fetch(url) {
   Js.log2("FetchResult response2", response2->Fetch.Response.status)
}

is that it seems to encourage happy-path programming. Each of these steps might fail and need different handling/logging, and currently ReScript forces me to think about that.

I would also prefer to look into optional chaining instead, and/or into guard syntax / early return (see rescript-lang/syntax#20).

[cristianoc]

Being a bit concrete with option chaining.
Setup:

type a = {a?: int}

type b = {b: a}

type c = {c?: b}

Let's assume x:c. Then:

x.c: option<b>
x.c?.b : option<a>
x.c?.b.?a : option<option<int>>

The last one is unlikely to be what one intended, as one cannot continue a chain from that. So one would need to invent some additional thing, say ??. so that

x.c?.b.??a : option<int>

This looks a lot like option accounting instead of expressing intentions efficiently.

[cknitt]

Did you mean

x.c?.b?.a : option<option<int>>

?

Basically the issue is map vs. flatMap:

x.c->Option.map(b => b.b)->Option.map(a => a.a)

vs.

x.c->Option.map(b => b.b)->Option.flatMap(a => a.a)

TypeScript let's you do just

type a = { a?: number };

type b = { b: a };

type c = { c?: b };

const f = (x: c) => x.c?.b.a;

(but of course cannot infer the type of f correctly if the type of x is not known)

[cristianoc]

Indeed.
Optional chaining fits well with TS, and is more complicated with ReScript in a way that's not clear how to work around.

In terms of records with optional values, there could be opportunities coming from having nominal typing. Namely, one might be able to directly infer user intent without any additional notation. Could be interesting to think about a little bit, and try to understand if such magic would come with undesirable gotchas.