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, 9/13/2019 #33422

Closed
DanielRosenwasser opened this issue Sep 13, 2019 · 3 comments
Closed

Design Meeting Notes, 9/13/2019 #33422

DanielRosenwasser opened this issue Sep 13, 2019 · 3 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Private Fields in .d.ts Files

#30829

  • One issue is that .d.ts files are sometimes lossy because private fields omit their types.
    • We probe the structure
  • The variance issue sounds like something we're not likely to address.
    • It's broken today for private, why change for #?
  • Perhaps it makes sense to just include a single #_ declaration in the output if we're just erasing all details.
    • Why don't we just include the original privates in the class declarations?
      • Because you don't want 30 privates in your classes?
      • But that's the case for private properties today.
    • Do private fields affect incremental and project references?
      • Yes, but they probably shouldn't.
      • A point in favor of emitting a single private property?
  • So #_?
    • #privateProperty just so people can search it online more easily.

Collisions of Imported Types

#31231

  • Introducing an error when types conflict with local type names.
import { foo } from "./stuff";
export type foo = foo;
  • Breaks legitimate errors in firebase-firestore, glimmer, skype, vscode.
    • VS Code examples seemed suspicious.
  • The general pattern is useful when running with isolatedModules, but there's no reason to use the same name.
  • This is a breaking change, but the break seems legitimate, existing code seems wrong, and the fix is simple.

@RyanCavanaugh has the other notes.

@mheiber
Copy link
Contributor

mheiber commented Sep 16, 2019

We implemented the proposed solution for private identifiers in .d.ts files using #private (bikeshedding of the name welcome). Explanation here. Thanks for your time and for the discussion!

@RyanCavanaugh
Copy link
Member

  • Class fields (private and otherwise)
    • Handle breaking change in class property runtime behavior #27644 Define vs Set
    • What do we do with type-only declarations of properties?
      • This is a problem regardless of Set vs Define
    • Need to make this.p = e in JS files not be treated like field declarations for the purposes of detecting these problems
    • Potential DT Breaks: skatejs, bookshelf
    • PR needs to not do checks against interface properties
    • In 3.7: Emit getters and setters in class .d.ts
    • When do we issue these errors?
      • Only when Define semantics are present?
        • What if you're using Babel to downlevel?
      • Is this a strict mode flag?
    • New flag that is off by default at first, then on
    • Emit
      • Do we need bidirectional flexibility here? Ugh
      • Do we need a way to declare a set-semantics field?
    • x; which means "set to undefined" in proposal
      • We need syntax to say "but don't initialize this"
        • declare x; is the logical choice

@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Sep 16, 2019
@Jessidhia
Copy link

What if you're using Babel to downlevel?

That'll depend on your Babel settings as well. Babel (7) will use Define by default, but if you pass the loose: true option to the transform it will use Set.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

4 participants