Realm.List subscript accessor ([]) has incorrect return type

[myou11]

How frequently does the bug occur?

All the time

Description

The return type for subscript access on a Realm.List seems to be incorrect. In the index.d.ts from the realm package, the definition of the subscript access is:

interface List<T> extends Collection<T> {
    [n: number]: T;
    .....

I think the return type should be T | undefined since specifying an n that is out of bounds does produce an undefined result.

Stacktrace & log output

No response

Can you reproduce the bug?

Yes, always

Reproduction Steps

No response

Version

10.20.0-beta.5

What SDK flavour are you using?

Local Database only

Are you using encryption?

No, not using encryption

Platform OS and version(s)

iOS 15

Build environment

Which debugger for React Native: ..
Hermes

Cocoapods version

1.11.2

[kneth]

@myou11 Thank you for reporting. As both Realm.List and Realm.Results mimics Array, undefined is returned if you are out of bound. The TypeScript definition needs to be fixed.

[kneth]

After studying it a bit more careful, I think the type is correct. From the discussion, it is on purpose that ReadonlyArray doesn't have T | undefined as return type for [].

[myou11]

Thanks for looking into this @kneth! I appreciate the linking to that Typescript discussion. After reading it, I understand why they have the return type as just T rather than T | undefined.
I do see that they have a tsconfig option noUncheckedIndexedAccess that provides the | undefined in the index signatures. Is there a way to get something like this for Realm.List and Realm.Results?

[kneth]

Is there a way to get something like this for Realm.List and Realm.Results?

Just to be clear, you only want it for Realm.List and Realm.Results? I mean, noUncheckedIndexedAccess affects all arrays.

The rationale behind our current types is to promote that you guard against out-of-range situations. It means, accessing an element should never return undefined.

[myou11]

After re-visiting this, the types provided are good! For my use case before, I was already having checks to guard against out-of-range situations. I realize enabling the noUncheckedIndexedAccess would be a bit too strict for all our other uses similar to what is discussed in the discussion you linked.

You can disregard this issue. Thanks for the discussion!