[m0meni]

Wouldn't this swallow errors that you wouldn't want it to swallow? e.g. you try to access a property on a value that's null (which you think isn't null), and instead of getting an error, nothing happens. Idx[0] is a way better solution to dealing with the boilerplate of checking for null/undefined that has 0 runtime cost due to being compiled away by babel. It works with type systems, and you can even use it as a babel macro[1].

With it

    idx(props, _ => _.user.friends[0].friends)

compiles to

    props.user == null ? props.user :
    props.user.friends == null ? props.user.friends :
    props.user.friends[0] == null ? props.user.friends[0] :
    props.user.friends[0].friends

Optional chaining[2] would add this to JS at the language level by using ?. as the operator.

[0]: https://github.com/facebookincubator/idx [1]: https://github.com/dralletje/idx.macro [2]: https://github.com/tc39/proposal-optional-chaining

[slmgc]

idx requires a transpilation step.

> you try to access a property on a value that's null (which you think isn't null), and instead of getting an error, nothing happens

You can check for Nothing if you know you shouldn't get one. It's not about swallowing errors, it's about removing try/catch and all this `a && a.b && a.b.c && a.b.c()` boilerplate code.

> Optional chaining[2] would add this to JS at the language level by using ?. as the operator

But it's not there yet and it will require a transpilation step for quite some time before all the major browsers will introduce this feature.

Nothing returns "safe" default values instead of null/undefined, which might come in useful in some cases. Also, it can be used in unit tests to mock some deeply-nested constructs.