Proposal: Static Typing

guest271314 guest271314 at gmail.com
Mon Mar 25 20:35:06 UTC 2019


```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 <viliuskubilius416 at gmail.com>
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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190325/c1114079/attachment-0001.html>


More information about the es-discuss mailing list