Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Meeting Notes, 8/12/2016 #10307

Closed
RyanCavanaugh opened this issue Aug 12, 2016 · 5 comments
Closed

Design Meeting Notes, 8/12/2016 #10307

RyanCavanaugh opened this issue Aug 12, 2016 · 5 comments
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

  • Map perf Optimize performance of maps (with ES3 support) #10298 / Optimize performance of maps #10270
    • Using Object.create(null) to produce maps increases overall perf ~15-20% and decreases memory ~20%
    • Avoids calls to hasOwnProperty
    • Breaks ES3 runtime use of tsc
    • Force object into 'Dictionary' mode in V8 (by using delete operator) to get better perf
    • Breaks compiler API
    • Two possibilities
      • Drop ES3 host support
        • Believe there's just the one guy doing this
      • Chakra and Node have been ES5 forever
      • Simplifies code
      • We have bugs here caused by bad property lookups
    • Keep ES3 host support
      • Requires guards in for loops
      • Need a wrapper to read a property from an object to avoid hitting other properties
    • 👍 drop ES3 host support
      • Are we allowed to use ES5 array methods in the compiler now?
        • Sure, might be faster but we have different behavior
    • What about ES6 maps?
      • No apples-to-apples comparison available yet
      • Probably not better, but worth trying
  • UMD globals Consider allowing access to UMD globals from modules #10178
    • JQuery always defines $
    • This used to be OK everywhere; psuedo-breaking-change
    • JQuery always defines $
    • The lack-of-error from before was not complained about
    • What does everyone do?
      • Conditionally make a global, in theory
    • Do nothing unless we see this more
    • JQuery always defines $
    • This is a trivial change in require.js
  • Partial downlevel generator support in transform branch [Transforms] Minimal authoring support for down-level generator functions #10106
    • Difficult to understand what the restrictions are
    • Bad to implement something where the primary use case (for/of) doesn't work
    • Is there a reasonable opt-in policy?
    • Avoid half-solutions
  • Narrowing any allow narrowing from any #9999 / catch type annotations Allow : { } / : any type annotations on catch variables #10000 / Can't narrow error type in catch clause #8677
    • Review of breaking changes: these are all acceptable or outright good
    • 👍 exclude narrowing to Function or Object (including when from UDTG)

/cc @DanielRosenwasser who I think has some better notes on the last two

@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Aug 12, 2016
@DanielRosenwasser
Copy link
Member

Performance Optimization using "Slow Objects"

We've achieved meaningful performance gains in #10270 & #10298 (~15% faster) through

  • "Hinting" to V8 that objects used as maps should not be optimized to classes (because they will get de-optimized).
  • Using Object.create to avoid prototype-climbing lookup.
  • Avoiding Object.hasProperty because we can modify the prototype ourselves.

This means that TypeScript as a compiler could not run on ES3 due to use of Object.create.

  • NOTE: TypeScript could still write to ES3.
  • However, reviewing the code, it looked like many places where we were operating on maps wouldn't have worked in ES3 anyway!
  • Much easier because we wouldn't have to worry about using the wrong operations on Maps.

Conclusion

Drop ES3 host support.

**NOTE that this DOES NOT mean we are dropping support for ES3 targets.

Allowing UMD globals in modules (#10178)

Issue: people were taking advantage of globals being introduced even though they were using modules.

  • Some modules conditionally bring their global in depending on how they're included.
    • One user's library only fathoms an entity globally if used in a script tag - switching to an import is not a valid fix.

Conclusion

Niche case, let's not do anything.

Downlevel Generators

  • Ron has worked on a minimal implementation of downlevel generators.
    • Differences: generators give you Iterator<T>, not IterableIterator<T> because Symbol.iterator may not be around.
    • Basically what we give for async functions.
  • Problem: but people will be incredibly confused when they try to for-of over a generator call.
    • Most people don't use or understand generators to begin with (whereas async/await has a clear demand).

Conclusion

Can't ship something that will only sometimes work.

Narrowing from any

Problem: we don't narrow from any to any specific types. This is technically not wrong, but it is more error prone.

Why can't we fix this?
Well imagine you did x instanceof Object which is one of the most restrictive types in the type system.
With Object, you can do effectively nothing.

Idea: narrow unless you are instanceof-ing on Object or Function.

Conclusion

In general, most code that is broken by this is questionable anyway.
Adding {} is an annoying pain.
Let's do it!

@aluanhaddad
Copy link
Contributor

aluanhaddad commented Oct 2, 2016

Differences: generators give you Iterator, not IterableIterator because Symbol.iterator may not be around.
Basically what we give for async functions.
Problem: but people will be incredibly confused when they try to for-of over a generator call.
Most people don't use or understand generators to begin with (whereas async/await has a clear demand).

@DanielRosenwasser can you clarify what you mean by "Symbol.iterator may not be around" and how that differs from a Promise polyfill may not be around.
Specifically how or why does the former preclude down leveling generator functions when the latter does not preclude down leveling async functions?

@chicoxyzzy
Copy link
Contributor

Most people don't use or understand generators to begin with (whereas async/await has a clear demand).

I was really... surprised... by this. This is really confusing!

@chicoxyzzy
Copy link
Contributor

There is #12346. Does it mean generators will be transpiled to ES3/ES5?

@mhegazy
Copy link
Contributor

mhegazy commented Dec 7, 2016

There is #12346. Does it mean generators will be transpiled to ES3/ES5?

yes. in TS 2.2

@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

5 participants