You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While Rune is dynamically typed it would sometimes be useful to have type annotations or hints, especially for the LSP. This can be especially useful when integrating rune as a plugin system in a larger program, with custom Rust native external types.
A concrete example is that I have custom script entry points (instead of main) that look like:
pubfngenerate_config(commands,settings){// Here the script should do things with methods on commands and settings to generate the system config in /etc}
Unfortunately even though the custom LSP knows about the types of commands and settings, it doesn't know that those parameters are of those types. My proposal is to add optional and informational type hints (similar to what python has):
pubfngenerate_config(commands:::mynamespace::Commands,settings:::mynamespace::Settings){// Here the script should do things with methods on commands and settings to generate the system config in /etc}
There are of course a bunch of design questions around this, but I believe all of these can be handled as "future extensions" in order to get an MVP done:
What about unions of types (e.g. this can be an int or a float). We could take an idea from Python here and have myparam: int | float or similar. For a MVP I don't think this is needed, and adding it later would not be a breaking change.
Where should type annotations be valid? I only need them on function parameters, but I can see them being useful elsewhere, such as on variables in pattern matches etc. I would suggest just parameter and let bindings to begin with and punt the rest to "future extensions".
What syntax to use? This is easy I believe, just copy Rust here (as has been done in other places already).
What about things like Vec<_> that causes Rust to do type inference? Again, this could be a future extension. Or we could let _ mean "any dynamic value".
The text was updated successfully, but these errors were encountered:
Sum types like int | float is something I want to avoid. Once type annotations is present I want to enforce strict typing. Not necessarily allow all Rune programs to be legally typed (like TypeScript does for JavaScript). The latter leads to a much more complicated type system.
So with typed Rune if you want to pass in an int or float, I think the encouraged pattern should be to use an enum.
Feel free to close this, though this issue goes into (a bit) more detail and motivation.
We'll probably end up merging all of the issues into one for easier discovery. For now, I'll leave this open.
While Rune is dynamically typed it would sometimes be useful to have type annotations or hints, especially for the LSP. This can be especially useful when integrating rune as a plugin system in a larger program, with custom Rust native external types.
A concrete example is that I have custom script entry points (instead of
main
) that look like:Unfortunately even though the custom LSP knows about the types of
commands
andsettings
, it doesn't know that those parameters are of those types. My proposal is to add optional and informational type hints (similar to what python has):There are of course a bunch of design questions around this, but I believe all of these can be handled as "future extensions" in order to get an MVP done:
int
or afloat
). We could take an idea from Python here and havemyparam: int | float
or similar. For a MVP I don't think this is needed, and adding it later would not be a breaking change.Vec<_>
that causes Rust to do type inference? Again, this could be a future extension. Or we could let_
mean "any dynamic value".The text was updated successfully, but these errors were encountered: