```js let a: number = 10
a += ‘1’ // Error, cannot convert type string to type number.``` What if ```"101"``` is the expected result? Would Strict mode for scripts <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode#Strict_mode_for_scripts> > To invoke strict mode for an entire script, put the exact statement ```"use strict";``` (or ```'use strict';```) before any other statements. ```"use static typing"``` suffice? On Mon, Mar 25, 2019 at 5:13 PM ViliusCreator <[email protected]> wrote: > > Hello, to play the devils advocate: why does JavaScript need static > typing? Your proposal doesn't really answer that. Sure, it mentions tooling > and IDEs that can provide you with type hints and complain on mistakes > > I actually did. It keeps unwanted type mutations and bad values away. For > example, > > This: > > ```js > > let a = 10 > > a += ‘1’ // ‘101’ > > // or > > a += undefined // NaN > > ``` > > VS this: > > ```js > > let a: number = 10 > > a += ‘1’ // Error, cannot convert type string to type number. > > // or > > a += undefined // Error, number doesn’t have nullable mark. > > ``` > > This can help developer itself, in runtime, not only at development time. > “But IDE wouldn’t allow that.” But what if property in required json(node > js), is undefined? Some IDEs don’t have JSON intellisense, so this is where > it can get annoying. > > > but things like Flow and Typescript do this today already. > > Yes, but they are compile-time only. Meaning, that in runtime, type > mutation and unwanted values can happen. > > > What's your goal, to have JS engines run Typescript(-like) code natively > without transpiling? > > First of, this is compiling. TypeScript is higher level than JS, so it’s > compiling. Second, TypeScript code is completely compile-time only. > Classes(And other ES8+ code), imports, exports and probably namespaces are > the only things which are at runtime also. > > > What's the point of building this feature into engines? It just provides > additional complexity. > > I said reasons above. Also as I said, they are optional. Meaning, new > comers can still learn old js code without static types. Besides, doesn’t > async, await, classes and other new stuff add complexity to new people to > JS? > > > Where (when) do you expect types to be checked? Should the engine throw > early errors (during parsing)? > > Languages normally check types during compile-time. I expect JS to throw > errors in runtime, meaning that if you make code which would throw type > error and it’s untouched, then it doesn’t throw an error. > > > What does "static typing" even mean to you in a dynamic scripting > language? > > Same thing as in real statically typed languages. Type checking. > > > and what happens when you introduce new types with `eval` or by loading > another script? > > Since as I said, they are runtime only type checking. > > > > > However I would be curious to know if anybody has a usage for them at > run time > > They have. `eval` can make type mutation(and if it checks the string, you > can still overcome them(inputs or array joining)). > > > > Also, if transpiling and compiling is better, why not leave JS dead? I > mean, compilers can do job instead of JS. It’s just basically useless, > compilers can do awesome stuff, so “no need for new features in JS”(and > then if we did, wasm would take over in web development, or browsers would > overcome ES and use something else instead). > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_1439268435014527978_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
