What I generally mean by "Type Safety" in TypeScript is that if I opened one of my TS files at random and put a typo in any variable at all, the compiler would catch it, and that's what I want. If I pass the wrong argument to a method, or try to access a property that is not on an object, again TS compiler catches it.
It's up to the developer (with TS) to be sure to use types for all variables (objects) but if you simply do that you do get what I can correctly call "100% TypeSafety" because I explained how I define what that safety means and 100% of my code is type safe in the way I just described.
"type safety and type soundness are the extent to which a programming language discourages or prevents type errors."
"A type error is an unintended condition which might manifest in multiple stages of a program's development. Thus a facility for detection of the error is needed in the type system."
Interestingly:
"TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe. When a type system has this property, it is said to not be “sound”. The places where TypeScript allows unsound behavior were carefully considered, and throughout this document we’ll explain where these happen and the motivating scenarios behind them."
Static analysis will catch typos but ultimately that has nothing to do with "type safety".
And if anything, ubiqutous langauge has taught us that we need to stick to previously agreed to meanings of existing terms in order to communicate effectively.
I think language terms derive their meaning based on context. For example, I can say C++ has "classes" and I can also say TypeScript/JS has "classes". Similarly the term "Type Safety" has a generally well understood meaning across the industry and across languages, although each language has it's own nuances.
I think language terms derive their meaning based on context.
…and switching contexts leads to expectations no being met.
Going from C++ to TypeScript means losing multiple inheritance and using interface instead of abstract classes (even though TypeScript supports those). Going further into JavaScript where "classes are a template for creating objects"; objects can be augmented during runtime to adopt behaviour that conflicts with the notion of "class membership". Meanwhile custom elements cannot be created with mere user-defined constructor functions (JS classes are not “just syntactic sugar”) because the native DOM implementation uses native classes.
As to typos.
Those were already caught with use strict which has been available since 2012. Of course that was runtime check. So language aware editors have been catching those for quite some time without typechecking and linting tools have also been catching those for a while via static analysis.
Typos will be caught during type checking; that's just something that has to be already satisfied before type checking can even start.
A large segment of the TypeScript community advocates not specifying function return types; specifying only parameter types specifies the function type only half-way. This seems to reflect a rather casual attitude towards type safety (as the consumer of the return value may also rely on type inference). For example, Rust also has type inference but requires function return types as those are part of the full contract; function return types are valuable typing check points.
And just recently I ran into an error that I didn't resolve by correcting types but by enabling TypeScript's strict mode.
I would argue that the driver behind TypeScript's adoption is mostly convenience (unless you're a library maintainer) rather than safety.
Glad your a fan of Type Safety! Every experienced developer is. Thanks for the primer on C++, but my first decade as a developer was C++, so I was aware. My second two decades were Java and WebApps.
I love how TS checks every line of my code for perfect compile-time correctness, but I also use a linter to catch even a rogue space at the end of a line, or whatever else which isn't even an error. lol.
What I generally mean by "Type Safety" in TypeScript is that if I opened one of my TS files at random and put a typo in any variable at all, the compiler would catch it, and that's what I want. If I pass the wrong argument to a method, or try to access a property that is not on an object, again TS compiler catches it.
It's up to the developer (with TS) to be sure to use types for all variables (objects) but if you simply do that you do get what I can correctly call "100% TypeSafety" because I explained how I define what that safety means and 100% of my code is type safe in the way I just described.
Current rendition from the great sink of human knowledge:
"type safety and type soundness are the extent to which a programming language discourages or prevents type errors."
"A type error is an unintended condition which might manifest in multiple stages of a program's development. Thus a facility for detection of the error is needed in the type system."
Interestingly:
"TypeScript’s type system allows certain operations that can’t be known at compile-time to be safe. When a type system has this property, it is said to not be “sound”. The places where TypeScript allows unsound behavior were carefully considered, and throughout this document we’ll explain where these happen and the motivating scenarios behind them."
Static analysis will catch typos but ultimately that has nothing to do with "type safety".
And if anything, ubiqutous langauge has taught us that we need to stick to previously agreed to meanings of existing terms in order to communicate effectively.
I think language terms derive their meaning based on context. For example, I can say C++ has "classes" and I can also say TypeScript/JS has "classes". Similarly the term "Type Safety" has a generally well understood meaning across the industry and across languages, although each language has it's own nuances.
…and switching contexts leads to expectations no being met.
Going from C++ to TypeScript means losing multiple inheritance and using
interfaceinstead of abstract classes (even though TypeScript supports those). Going further into JavaScript where "classes are a template for creating objects"; objects can be augmented during runtime to adopt behaviour that conflicts with the notion of "class membership". Meanwhile custom elements cannot be created with mere user-defined constructor functions (JS classes are not “just syntactic sugar”) because the native DOM implementation uses native classes.As to typos.
Those were already caught with
use strictwhich has been available since 2012. Of course that was runtime check. So language aware editors have been catching those for quite some time without typechecking and linting tools have also been catching those for a while via static analysis.Typos will be caught during type checking; that's just something that has to be already satisfied before type checking can even start.
A large segment of the TypeScript community advocates not specifying function return types; specifying only parameter types specifies the function type only half-way. This seems to reflect a rather casual attitude towards type safety (as the consumer of the return value may also rely on type inference). For example, Rust also has type inference but requires function return types as those are part of the full contract; function return types are valuable typing check points.
And just recently I ran into an error that I didn't resolve by correcting types but by enabling TypeScript's strict mode.
I would argue that the driver behind TypeScript's adoption is mostly convenience (unless you're a library maintainer) rather than safety.
Glad your a fan of Type Safety! Every experienced developer is. Thanks for the primer on C++, but my first decade as a developer was C++, so I was aware. My second two decades were Java and WebApps.
I love how TS checks every line of my code for perfect compile-time correctness, but I also use a linter to catch even a rogue space at the end of a line, or whatever else which isn't even an error. lol.
If you get bored check out my project here: quanta.wiki/tab/feed