#1917·fp-ts

Improving option.getOrElse type inference

Author: vinassefrancheCreated Dec 7, 2023Updated Mar 4, 2026

Feature request

Current Behavior

Today, when using option.getOrElse, the type of what's inside the option is inferred from the first argument (the or else argument). This leads to typescript easily erroring when returning an array or an option.none (non exhaustive list):

typescript
declare const foo: Option<ReadonlyArray<string>>
pipe(
  foo,
  option.getOrElse(() => []),
)
// ts error: Argument of type 'Option<readonly string[]>' is not assignable to parameter of type 'Option<never[]>'.

To fix this, I can use getOrElseW but the resulting type will be not that great (readonly string[] | never[]) or enforce the type like this:

typescript
pipe(
  foo,
  option.getOrElse<ReadonlyArray<string>>(() => []),
)
// -> no error when getOrElse is typed

Desired Behavior

It would be great that the inference would be done from the option that is passed to getOrElse instead so that this would be valid code:

typescript
declare const foo: Option<ReadonlyArray<string>>
pipe(
  foo,
  option.getOrElse(() => []),
)

Suggested Solution

Use NoInfer from ts-toolbelt. Here's the implementation if we don't want to add a new dependency:

typescript
type NoInfer<A extends any> =
    [A][A extends any ? 0 : never]

and use it like this:

typescript
export declare const getOrElse: <A>(onNone: LazyArg<NoInfer<A>>) => (ma: Option<A>) => A

Who does this impact? Who is this for?

This can impact any user and would help greatly new users that don't understand why typescript is not happy.

Describe alternatives you've considered

None

Additional context

Your environment

Software Version(s)
fp-ts 2.16.1
TypeScript 5.3.3