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/25/2017 #18155

Closed
DanielRosenwasser opened this issue Aug 30, 2017 · 2 comments
Closed

Design Meeting Notes, 8/25/2017 #18155

DanielRosenwasser opened this issue Aug 30, 2017 · 2 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Add promised type (continued)

#17077

  • Never had a name for this.
    • await?
    • awaited?
    • Positive sentiment for both.
  • How bad is the world without this?
    • Well stricter generic checks broke a lot of checking.
    • But are things fixed now? We've gotten this far without it.
  • Would love to see specifically why we need to do this.
    • PR has some examples.
  • At the end of the last meeting we had two open issues:
    • Naming
    • Highed order relationships.
  • What if we just worked on some of the inference issues that Promise/PromiseLikes experience relating to union type inference?

String enums and indexing

  • Now that string-enums are a thing, people want to use them everywhere, like in

    • interface/literal types.
    • computed properties
  • Would need to generalize declarations constructed with literal types:

    const b = "b";
    const x = {
        [b]: 100,
    }
    
    // equivalent to
    
    const y = {
        b: 100,
    }
  • What would we do in the case of

    declare const x: "a" | "b";
    const a = {
        [x]: 100,
    }
    • Is that

      //    { a: number } | { b: number }
      // or
      //    { a?: number, b?: number }
      // or
      //    { [x: string]: number }
  • Leaning towards last option for practicality.

  • What about cases where you want to quickly manufacture distinct cases?

    function createThing<K extends "a" | "b", payload: T>(kind: K, payload: T) {
        return {
            kind,
            payload: {
                [kind]: T,
            }
        };
    }
    
    createThing("a", 100);
    • Could boil this down to @gcanti's Unionize.
      • type m = { [P in "a" | "b" ]: { [Q in P]: number } }["a" | "b"];
        • Becomes type m = { a: number; } | { b: number; }
@xealot
Copy link

xealot commented Jan 9, 2018

My opinion (from #21030) is obviously to be more specific. In your example for string enums and indexing it would be the: { a: number } | { b: number } option.

@DanielRosenwasser
Copy link
Member Author

DanielRosenwasser commented Jan 9, 2018

Linking to #21070.

@microsoft microsoft locked and limited conversation to collaborators Jul 3, 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

3 participants