Comments (5)
I support this. It's very annoying to have to provide types even for things you don't care to type check for. Especially when the types you'd declare are not source of truth anyway because you are using third party code. Maybe an optional warning for traversing such "any" or "unknown" types would be useful as well
from tl.
Another potential way to frame this syntax-wise is similarly to Rust's unsafe. Make it so any type errors within unsafe ... end
are ignored. That's probably less ergonomic though, as usually most of the types are known, and it's just one or two values which are unknown
from tl.
Thank you for the feedback!
A behavior similar (but not identical) to what you asked for currently exists in the unknown
type, which is the implicit type of variables that are not annotated. When a file has a .lua
extension, the compiler goes into "lax" mode, and anything about unknown
variables is ignored, other than reporting their existence as warnings.
The idea was that one would take their .lua
file, start running tl check
on it, get a zillion unknown
warnings, and start type-annotating them gradually, to the point where the file is fully annotated, then it becomes a .tl
file, which can then be checked in the default "strict" mode. Of course, .lua
files with partial annotations are not proper Lua files, so that was meant as a temporary state. But at least that makes the conversion process less grating than starting with a zillion errors (because in "strict" mode the errors due to insufficient annotation propagate a lot more).
What I didn't want is to be too lenient on missing annotations, to avoid the situation you see in TypeScript where people abuse any
in places that could be typed trivially, so dissuading people from reaching out to any
all the time is a constant concern in the TS world.
Note that in Teal, the any
type has semantics that match TypeScript's unknown
type: the only thing you can do with it is pass it around, or cast it. Effectively, the names any
and unknown
have opposite meanings in TS and Teal, with the difference that currently in Teal you cannot explicitly declare a variable as unknown
. Another problem in TypeScript is that people often use TS any
(their "do anything with it" type) in places where they really intended to use TS unknown
(their "just pass it around" type). Teal started cautiously, by only exposing the "just pass it around" type.
In short, in lax mode, Teal's unknown
type is the "do anything with it" type, and it does have the behavior you suggested for dynamic
. I still don't like the idea of exposing unknown
as a free-for-all and ending up in a situation like TypeScript's where it over-proliferates, but I'm taking your feedback as a sign that finding a middle ground should be considered. Perhaps allowing explicit unknown
but triggering a warning by default? I'm not super happy with that option, but I'll keep thinking and I'm open to more ideas and feedback.
from tl.
Regarding the source of truth in typing for third-party libraries, that's a common dilemma when going from untyped to typed code. The preferred approach is to declare .d.tl
files with the typing info of those untyped Lua libraries, and having that be the clear boundary within the untyped and typed worlds, ideally producing reusable declarations like the ones we have in the teal-types repo (even if the DX ergonomics for that are not fully solved yet). I wouldn't want for people to stop contributing type declarations and just start to use unknown
everywhere they use a Lua library instead.
from tl.
I wanted to add provide a bit more context and feedback as someone looking to incorporate Teal into my existing Lua project. I recently learnt about Teal and was very excited because I had previously moved a project from Javascript to Typescript and the experience was great. However, when it comes to Teal I have greatly struggled to migrate.
My sense is that Teal is not really about gradual typing as much as TS is. Requiring .lua files into .tl files practically compels you to rewrite the code unless you write a .d.tl file for every .lua file and maintain them alongside your .lua code. I really like the suggestion mentioned above for adding unsafe blocks. Probably adding a require_unsafe() to require .lua code without having to provide type annotations can also be an interesting feature. I really believe focusing on gradual typing can make it much easier for developers like me who want to bring type checking into their lua codebases.
from tl.
Related Issues (20)
- No errors reported when assigning value directly to a record table
- Function does not enforce argument record type if variable type is inferred
- Type alias for nested generic crashes compiler HOT 1
- [next] `self` cannot be constrained by an interface
- [next] interface methods
- Possible Typechecking Failure on Union Return HOT 2
- unexpected propagation of <const> attribute HOT 1
- missing narrowing type when not simple expression
- Inconsistencies between string escapes in Lua versions are not handled by Teal
- Feature request: Ability to rename the compiled files using regex HOT 2
- weird shadowing behavior regarding generic type names HOT 2
- reexport a nested table type HOT 1
- How do i solve this error? : argument 2: got type constant (alias), expected constant HOT 2
- flow-typing of return types at odds with polymorphic functions
- Support forward declarations, at least in a record HOT 3
- Nested record metatable issue? HOT 1
- [next] declaration of record methods does not work for aliased types HOT 2
- [next] union type does not specialize with and-or idiom
- [next] type alias definition gets confused with generics
- [next] Internal Compiler Error on `tl types` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tl.