> Would an error at runtime or compiletime occur here?

There's no "compile time" per se in ES, but setting b += '1' when b is
strictly typed shouldn't throw an error at all. The type of the '1' would
be coerced to a number first, then added to b.

If instead it was something like
```js
let a: string = "1";
let b: number = 2;
b += a; //TypeError
```
This would cause an error because it would be invalid to coerce a into a
number.

> If it is a runtime error, is it optimal for the engine to keep track of
typed variables vs regular for the same value?

Engines like V8 already keep track of the type of variables. Static typing
would simply add a flag to these types that prevents type coercion if set.

On Wed, Mar 27, 2019 at 7:20 PM guest271314 <[email protected]> wrote:

>
>
> ---------- Forwarded message ---------
> From: guest271314 <[email protected]>
> Date: Thu, Mar 28, 2019 at 12:19 AM
> Subject: Re: Proposal: Static Typing
> To: Claude Pache <[email protected]>
>
>
>
> > `a = object[Math.random() < 0.5 ? "method_returning_number" :
> "method_returning_string"]()`
>
> Interesting case. See also
>
> How do I check if a JavaScript function returns a Promise?
>> <https://stackoverflow.com/q/43416214>
>
> Say I have two functions:
>> ```function f1() {
>>     return new Promise<any>((resolve, reject) => {
>>         resolve(true);
>>     });
>> }
>> function f2() {
>> }```
>> How do I know if f1 will return Promise and f2 will not?
>
>
> Can a regular expression be crafted which determines the return type of a
> function? <https://stackoverflow.com/q/43417236>
>
> Has it been mathematically proven that antivirus can't detect all viruses?
> <https://security.stackexchange.com/q/201992>
>
> On Wed, Mar 27, 2019 at 6:10 PM Claude Pache <[email protected]>
> wrote:
>
>>
>>
>> Le 27 mars 2019 à 18:26, Michael Theriot <[email protected]>
>> a écrit :
>>
>> Would an error at runtime or compiletime occur here?
>>
>>
>> The check cannot be reliably done at compile time in general; it must be
>> a runtime check. (Tools may provide partial static analysis, but that’s an
>> extra.)
>>
>> The simplest reason is that statically typed code must run together with
>> non-statically typed code.
>>
>> And even ignoring legacy code, it is not desirable to have static types
>> everywhere; for instance, `Array.prototype.sort()` must continue to work
>> with both arrays of strings and arrays of numbers, and even with arrays of
>> mixed types.
>>
>> And even if everything everywhere was statically typed, you still cannot
>> statically analyse situations like: `a = object[Math.random() < 0.5 ?
>> "method_returning_number" : "method_returning_string"]()`.
>>
>> If it is a runtime error, is it optimal for the engine to keep track of
>> typed variables vs regular for the same value?
>>
>>
>> Today’s JS engines typically do already clever speculative optimisations
>> based on expected types. For example:
>> https://stackoverflow.com/a/46144917. So, I guess, it depends...
>>
>> —Claude
>>
>> _______________________________________________
>> 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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to