Design Meeting Notes, 6/6/2016

[DanielRosenwasser]

Changes to Automatic Type Definition Inclusion

2 locations of interest for type inclusion:

1. Special inclusion folder (i.e. `types`)
2. `node_modules/@types`
    * How do you find this folder?
    * Started out with walking from `tsconfig.json`, looking at sibling `node_modules`.
    * What about the loose file case? DR found case where tsconfig is not next to `node_modules`? Often happens with test folders.
        * New behavior is walking up the spine to the first dir found.

          ```
          node_modules
            @types
                A
                B
          types
            B
            C
          ```

        * What about watching behavior?
            * That could be a little tricky - you'd be watching the entire strucutre.

Still working on PR, need to iron out a few issues with test runner.

Narrowing Constants in Function Declarations (#8976)

With last week's behavior, this works:

declare const x: string | string[];

function doSomething() {
    if (Array.isArray(x)) {
        var f = function f() {
            x.push("");
        }
        return f;
    }
    return undefined;
}

But not if you change f to be a function declaration:

declare const x: string | string[];

function doSomething() {
    if (Array.isArray(x)) {
        function f() {
            x.push("");
        }
        return f;
    }
    return undefined;
}

• Has differing behavior in strict mode.
  • See here.
• Could say that every global variable is uninitialized on entry to every function.
  • That would be an awful experience.
  • But you can't discriminate that well.
  • Any in-betweens will feel inconsistent.

(discussion)

We don't think many people would end up running into this.

Enums and Algebraic Data Types

As we ended up at last week, enums and ADTs are orthogonal. We already have tags.

Index signature parameter types (#5683)

• Basically boils down to indexers that take types that are subtypes of string (or number).

Have to think more on this.

Non-nullability issues with class properties

• User proposed checking whether non-nullable properties are initialized within the constructor.
  • Only fixes some problems - virtual calls, indirect method invocations. Not clear what the user wants.
• Could give users a way of saying that a method initializes a property
  • Now you're just repeating yourself to the compiler (initialization itself as well as declaring that you're doing so).
• Would really not do a compiler switch.
  • Too coarse-grained.
• Maybe some sort of modifier?
  • Bang?
• We don't have a way of understanding the lifetime of any of these members - don't track what happens in super calls, method calls.
• May be better to not do anything at all, people can use basic syntactic lint rules.
• We'd love to do something, but it's not clear anything we could do would truly be desirable.