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

Suggestion Backlog Slog, 3/6/2017 #14490

Closed
RyanCavanaugh opened this issue Mar 6, 2017 · 1 comment
Closed

Suggestion Backlog Slog, 3/6/2017 #14490

RyanCavanaugh opened this issue Mar 6, 2017 · 1 comment
Assignees
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Mar 6, 2017
@RyanCavanaugh RyanCavanaugh self-assigned this Mar 6, 2017
@RyanCavanaugh
Copy link
Member Author

  • Proposal: int types #4639 int types
    • Just not all that useful
    • ES is looking at adding int64
    • Revisit but 👎 unless we do Web Assembly
  • Allow attaching a comment before all non-user injected code. #13455 Allow attaching a comment before all non-user injected code.
    • When exactly would we emit this line?
      • Always? Only when we emit a new branch ?
      • Do our helpers suffer from this?
    • Where does this happen?
      • Can you just regex the output?
    • We could use a helper instead (makeSuper(_super, this))
    • AMF
  • Pure annotation in downlevel emits #13721 Pure annotation for class emit
    • Needed for accurate tree shaking
    • Somewhat odd Uglify doesn't identify this by itself?
    • Would be emitted for classes without static initializers
    • Could be implemented by an emit transform pipeline
      • But doesn't solve tsc scenarios
      • Probably OK
      • Actually this doesn't work bescause the injection has to happen between the class emit and the IIFE emit
    • Punt to uglififer to detect this pattern instead?
    • Make loaders handle this instead?
    • Daniel will try to do this for WebPack
  • Exact Types #12936 Exact Types
    • Excess property checks are already pretty good
    • Which types are exact and which aren't?
      • People may disagree
    • Some APIs really are closed
    • Sidebar on all-optional interfaces
      • Ryan should implement this and stop complaining
    • What is the behavior of this for unions / intersections?
      • Intersection... makes no sense?
        • Violates basic assumptions of assignability (T & U assignable to T)
    • What does it mean to be constrained by an exact type?
    • What about instantations of exact types?
    • Danger of bug farm
    • What is the value add here?
    • What about creating automatically-disjointing unions?
    • Outcomes
      • Need specific scenarios - is this an XY problem solution?
      • We need to fix excess property checking when the target is a union type
  • tsc -w should clear screen before each run #13020 tsc -w should clear screen before each run
    • Universal acclaim in the room for this behavior
    • 👍
    • Sidenote: Accept PR to get rid of WScript host
  • Allow classes to extend from values of type any #14301 Allow extends from any (Salsa)
    • 👍
    • When this happens, add a [s: string]: any signature to the type
  • Should 'Partial<T>' and Readonly<T> should have their type parameters constrained to 'object'? #14249 Constrain Partial<T>/Readonly<T> to T extends object
    • For shallow variants only
    • Breaking change...
    • 👎 Annoying as hell and delivers no value
  • Unsafe type-incompatible assignments should not be allowed #14150 strictVarianceChecks flag
    • Highly infectious
      • Could anyone actually get this to work?
      • You actually can't do this without the entire set of C++-like const constructs
    • Keep tabs on this
  • Generalize never type handling for control flow analysis based type guard #12825 Generalize handling of never for returns
    • The control flow graph is formed during binding, but we don't have type data yet
    • We could store all calls at each flow control point and then check them for never returns and check this info for computing types
      • Expensive!
    • Correct analysis would require multiple iterations
    • Possible solutions?
      • At bind-time
        • Detect explicit : never functions
          • Or do this at parse time?
        • Store potential calls to these
      • Use this to set up a "better" flow control graph
      • Above doesn't really work due to imported identifiers...
    • No clear answers in sight

Cut for time

@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

1 participant