Problem

Because of the way types are inferred in both TypeScript and Flow, it's possible for the NSV (Not-set value) of the first() and last() methods to be inferred incorrectly. For example:

const good = List<number>().first(); // Type is properly inferred as number | undefined, because the list may be empty
const bad: number = List<number>().first(); // This is not a type error, even though the types should not be compatible

This is quite subtle and it's easy for it to go unnoticed (for example, this went unnoticed for several years in our company's moderately large TypeScript codebase with ~2000 TypeScript files and ~200,000 lines of code). But it can cause bugs because it makes it easy to accidentally ignore the fact that the list may be empty.

Fix

This PR adds type tests for the above case, and fixes the types by updating first() and last() to use method overloads for the no-argument case. Note that this makes the types the same as the get() method, which already uses a method overload and doesn't suffer from this problem.

Technically this is a breaking change to the types: if this change is released, people will likely get some type errors when they upgrade to the version with the fix. However, those should all be places where there is a potential bug due to ignoring the possibility of the list being empty. If people want to ignore the error, they can do so using a ! assertion (e.g. .first()!).

Prior art

• This PR from 2018 made the exact change to the first()/last() types that the current PR does: Add separate types for Collection first()/last() with zero arguments #1653
  • The original intent of the PR was to fix a slightly different issue, but the creator of the PR later pointed out the above issue in a PR comment: Add separate types for Collection first()/last() with zero arguments #1653 (comment). They suggested .get(0) as a temporary workaround, meaning even at that time the types for get() were correct. There was never a reply to this comment, so it may have simply been unnoticed.
• That PR was rejected, and ultimately superseded by this PR from 2019: Provide default type to first() and last() #1676
  • This fixed one issue with the types for first() and last(), but did not fix the issue described above.