Skip to content
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

TextService.FilterStringAsync wrong undefined return type #538

Closed
Felyrun opened this issue Mar 7, 2022 · 5 comments · Fixed by #546
Closed

TextService.FilterStringAsync wrong undefined return type #538

Felyrun opened this issue Mar 7, 2022 · 5 comments · Fixed by #546

Comments

@Felyrun
Copy link

Felyrun commented Mar 7, 2022

API Reference (https://developer.roblox.com/en-us/api-reference/function/TextService/FilterStringAsync) says that TextService.FilterStringAsync returns a TextFilterResult (and not nil), but the return type here is TextFilterResult | undefined.

@Dionysusnu
Copy link
Contributor

For reference, custom definition was first added in a3aa48d with no further type changes after that.

@osyrisrblx
Copy link
Member

osyrisrblx commented Mar 7, 2022

Actually it was 7003fdd where the change happened

@Validark
Copy link
Contributor

Looks like I changed it by mistake? The documentation from 2019 is pretty much the same as it is today. I'm surprised no one noticed in 3 years. I wonder if anyone wrote a check in their code to make sure the return result is defined because of these types, or would they just have used type assertions?

@Dionysusnu
Copy link
Contributor

I wonder if anyone wrote a check in their code to make sure the return result is defined because of these types, or would they just have used type assertions?

Considering this is an HTTP request and a critical part of user safety, I would say this is a good thing and have just kept the type with undefined, considering, as you say, no one ran into it for 3 years. Sometimes an overly restrictive type can be good for code style.

@Validark
Copy link
Contributor

Well, if it's impossible for the API to return nil, there isn't any point to checking it. I don't see how it could be beneficial to write extra code and take up mental resources to deal with a situation that could never happen. I went ahead and changed it back to being always defined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants