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

Strings should be literally inferred where possible #613

Open
ghost opened this issue Jul 26, 2022 · 2 comments
Open

Strings should be literally inferred where possible #613

ghost opened this issue Jul 26, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Jul 26, 2022

Currently, all string values will be inferred as string, even if the literal value of the string is known

In the following example, it should be safe to assume the literal value of the string in multiple places

local function foo(bar: string)
  if bar == "Hello World" then
    --bar can be safely inferred as "Hello World"
  end
  return bar
end

--this is a really bad example
local function stringAsGeneric<T>(str: T): T
  return str
end

local a = stringAsGeneric("Hello World") --> a should be inferred as "Hello World"
local b = "Hi"
local c = stringAsGeneric(b) --> c should be inferred as the type of b which is "Hi"

If the value of the string cant be guaranteed, ie: RemoteEvent connection, it should fall back to string
I assume there is some technical reason for this not already being possible

@ghost ghost added the enhancement New feature or request label Jul 26, 2022
@ghost
Copy link
Author

ghost commented Nov 18, 2022

Here's another place where literal string inference would be useful, take a generic map definition

local function SomethingWithMaps<K>(map: {[K]: any})

end

SomethingWithMaps {
  Cat = "meow"
} --> type of generic would be {Cat: "meow"}

@vegorov-rbx
Copy link
Collaborator

The last example will infer overly restricted types right now.

Less restrictive types will become available once these RFCs get implemented: #77 and #79
But user type annotations will likely require #284 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants