Definitelytyped: Should e. g. `last` potentially return undefined?

[dbartholomae]

If you know how to fix the issue, make a pull request instead.

• [X] I tried using the @types/xxxx package and had problems.
• [X] I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• [X] I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• [X] [Mention](https://github.com/blog/821-mention-somebody-they-re-notified) the authors (see Definitions by: in index.d.ts) so they can respond.
  

  - Authors: @TheHandsomeCoder @donnut @mdekrey @mrdziuban @sbking @afharo @teves-castro @1M0reBug @hojberg @samsonkeung @angeloocana @raynerd @moshensky @ethanresnick @leighman @deftomat @deptno @blimusiek @biern @rayhaneh @rgm @drewwyatt @jottenlips @minitesh @krantisinh @pirix-gh @brekk @nemo108 @jituanlin @Philippe-mills @Saul-Mirone

If you do not mention the authors the issue will be ignored.

Situation now

E. g. last will return undefined if given an empty array, but the typing does not yet show this:

import { last } from 'ramda'

const numbers: number[] = []
const lastNumber: number = last(numbers)
// Not an error, so the following will not be caught:
console.log(lastNumber.toString())

Expected situation

I would expect last to be typed as function last<T>(array: T[]): T | undefined so TypeScript warns me about having to handle this case.

Proposed solution

I'm willing to add a PR, but this would be a breaking change to the types and could cause much headache. Furthermore, last is not the only function this is relevant for. So first I want to understand from the regular maintainers how to best proceed and whether this is helpful at all :)

[millsp]

Good point. Your PR is welcome. Which other types were you thinking about?

[millsp]

However, it is not limited to ramda, the edge-case applies to TS too:

const array: number[] = []

const item = array[0] // number
// assumes that it is populated

Maybe this could be a TypeScript issue on its own.
I'd like to know what other maintainers think (cc @sandersn)

[sandersn]

For typescript proper, we considered it and thought that it was too inconvenient to force a check on every access. I'm not aware of languages that require checking the result of the default method of array access, in fact. Even Haskell throws.

For a library the considerations are different. I would personally not make such a large change to ramda since it has lots of users, but would try to find a way to add a checked variant.

[dbartholomae]

Just read through all the threads in TypeScript on the topic, and it seems to be a design decision that still attracts some discussion. If I understood correctly, the TypeScript team explicitly encouraged that libraries might take a different decision so that users can decide whether they want a strict type-safe variant from a library, or a version with slightly less "boilerplate" without one. So personally I would be in favor of adding it to the ramda typings.
This change will only affect those who have strict null checks enabled, but it is still a breaking change, so I like the idea of adding a checked variant. Only thing that comes to my mind is adding a generic as a flag, but this feels awefully hacky :-/
What are your thoughts? :)

[millsp]

It's a regression on the types, this used to work (not long ago) the way @dbartholomae described, see https://github.com/DefinitelyTyped/DefinitelyTyped/pull/40254#issue-338828444

[cuchi]

The only reason we used head and last from Ramda (outside of point-free code) was to ensure null safety during some array manipulation in our TS projects.

This is very helpful for those who use the strict option of TypeScript

Since it is a somewhat recent regression, I also think it would be a good idea to bring it back to the library (#40254).

[cuchi]

40254 Was just merged and published, this issue is solved.