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, 4/21/2017 #15360

Closed
DanielRosenwasser opened this issue Apr 24, 2017 · 0 comments
Closed

Design Meeting Notes, 4/21/2017 #15360

DanielRosenwasser opened this issue Apr 24, 2017 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Apr 24, 2017

Check non-optional properties initialized in constructor (#8476)

  • Why are we revisiting?
    • The --strict flag makes it easier to surface these highly specific checks.
  • Ideas
    • Ensure that values are initialized at every point of exit in the constructor body.
    • But this doesn't completely guarantee coverage for checks because of super() calls and virtual methods.
      • i.e. what if methods override and don't initialize appropriately?
  • But there's definitiely people bitten by this.
  • Not clear that this is the desirable behavior in --strict.
    • --strict is what we believe to be the the set of ideal settings for writing new code.
    • What makes this more desirable that --noImplicitReturns?
      • That was a toss-up as well.
  • What about Angular and the like? They wouldn't be able to use this flag.
    • Angular codebases (especially ones made by angular-cli) and the like should be explicit about their strictnesss options.
    • Or they could explicitly turn it off when upgrading projects.
  • Resolution: Let's do it, experiment

String enums (#3192)

  • Today, emulating string enums can be done with the following hack:
namespace Color {
    export const None = undefined;
    export type  None = undefined;

    export const Red: "red" = "red";
    export type  Red = typeof Red;

    export const Green: "green" = "green";
    export type  Green = typeof Green;

    export const Blue: "blue" = "blue";
    export type  Blue = typeof Blue;
}

type Color = Color.None | Color.Red | ...;
  • Questions & ideas

    • Syntax
      • Would be great not to need another modifier on enums.
    • Should we produce a new type for each enum member?
  • Idea

    1. Enum with non-literal members.
    2. Enum with only numeric literal members.
    3. Enum with only literal members, some of which are non-numeric.
  • Should each enum member widen?

    • Do they widen to string or to their base enum type?
    • Most people agree base enum type.
  • Reverse indexing?

    • Probably wouldn't be able to do that?
  • Question:

    • What happens when you have Color.Red | Alert.Red and they refer to the same literal type?

Out of time.

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