-
-
Notifications
You must be signed in to change notification settings - Fork 546
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Strict Get
#313
Labels
Comments
Yes, I'm open to making the existing |
sindresorhus
added
enhancement
New feature or request
help wanted
Extra attention is needed
labels
Nov 8, 2021
Cool! I guess changing the existing type could be handled in one of three ways:
Do you have a preference? |
Opt-in through a type argument for now and we can make it opt-out in the next major release. |
Merged
What is wrong about GetStrict? |
@danielo515 Nothing in principle I guess, but I suspect it could easily lead to a lot of stuff having to be duplicated |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
Get
type is incredibly helpful, so thank you for that!There is, however, one thing that I wish for. I'm a big fan of defensive typing, and in that regard the
Get
type has the same shortcoming as nativeObject[Key]
type expressions do: the resulting type doesn't encode failure when dealing with arrays/dictionaries, even whennoUncheckedIndexedAccess
is enabled. F ex.Get<string[], "[1000000000000000000000000]">
has the typestring
instead of the more defensivestring | undefined
.In general this is easy to get around in userland, but looking at the implementation for
Get
it doesn't seem like a local proxy type is a feasible way of solving this.Would you be open to changing the
Get
type or to adding something like aGetStrict
? If so then I'd be happy to do the actual workThe text was updated successfully, but these errors were encountered: