One thing is definitively true. Any static type system added to ES must not be mandatory. Untyped code must be able to call typed code without forcing references into a fixed type. Likewise, typed code must be able to call untyped code without forcing references to give up type guarantees.
On Sun, Mar 24, 2019 at 8:48 PM kai zhu <[email protected]> wrote: > i share a similar concern that static-typing makes little sense in > high-churn-rate UX-workflow-programming. > > it encourage people to bikeshed for correctness, on low-level code that > frequently gets rewritten every few weeks/months -- and with often > demoralizing effects. > > > On 24 Mar 2019, at 17:26, Bergi <[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, but > > things like Flow and Typescript do this today already. > > What's your goal, to have JS engines run Typescript(-like) code natively > > without transpiling? For backwards-compatibility you'd have to do that > > anyway, especially if new type system features are introduced > incrementally. > > > > What's the point of building this feature into engines? It just provides > > additional complexity. Not to mention the difficulty of finding a > > suitable type system that is both sophisticated enough to describe all > > useful code (not taking away too much flexibility) and simple enough to > > understand without a CS degree. And which interfaces well with un-typed > > completely dynamic code. > > > > What does "static typing" even mean to you in a dynamic scripting > > language? JavaScript is not compiled by the developer, it is run by the > > user. Where (when) do you expect types to be checked? Should the engine > > throw early errors (during parsing)? During parsing of which parts of > > the code, even when "normal" (untyped) code is calling into typed code? > > Or do you expect dynamic runtime errors, like when assigning an invalid > > value to a "typed variable" or calling a "typed function" with wrong > > arguments? Are type definitions completely constant or could they be > > mutated/extended/etc dynamically (and what happens when you introduce > > new types with `eval` or by loading another script)? > > > > A proposal would need to provide an objective that answers all these > > questions, before even considering any particular type system or syntax. > > > > One way to go forward that I can see would be a proposal that reserves a > > relatively unrestricted syntax for type annotations (which are already > > considered during every grammar amendment anyway, for compatibility with > > Flow/Typescript), but not assign any semantics to them and require > > engines to simply ignore them. External tooling could then use these > > annotations according to its own rules. > > > > kind regards, > > Bergi > > _______________________________________________ > > 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
