Suggestion Backlog Slog, 6/15/2016 maybe

[RyanCavanaugh]

• Partial classes  #563 / Suggestion: Reopen static and instance side of classes #2957 Partial Classes
• Allow enums of types other than number #1206 Allow enums of types other than number / Boolean literal types and return type propagation for generators #2983 Boolean literals
• Default generic type variables #2175 Generic type parameter defaults
• T.constructor should be of type T #3841 / new myVariable.constructor() doesn't compile #4356 .constructor properties of static and instance sides
• namespace / module: Duplicate declaration & needlessly remove line-breaks #5553 Add an extra line break after module block in emit
• Add explicit error to __extends when base class is undefined #5794 Add a check to __extends to produce a useful error when base class is undefined
• Make functions generic when contextually typed by a generic signature #5737 Use nongeneric parameters from generic signatures when contextually typing

[tinganho]

Just curious what "slog" means?

[kitsonk]

slog:

to keep doing something even though it is difficult or boring : to work at something in a steady, determined way

[RyanCavanaugh]

These haven't been covered yet

[DanielRosenwasser]

Partial Classes (#563)

Assume

class X {

}

The question is whether

partial class X {
    foo() { }
}

should be equivalent to

interface X {
    foo();
}
X.prototype.foo = function() { }

• Last time we discussed this, only thing we didn't like about this was the partial keyword.
  • However, most people are asking for specifically that.
• What about when ordering is incorrect? (e.g. using a partial extension method before it's defined).
  • That's a risk you're dealing with for augmentations anyway.
• Resolved: all modifiers on a class must agree.
  • Except the first class, where that cannot be partial.
• How do augmentations work with imports?

  • If this doesn't work with modules, it isn't worth doing.

  • With augmentations today, you write this as

    import { Foo } from "./a";
    
    // Module augmentation.
    declare module "./a" {
        // interface merging
        interface Foo {
            y(): void;
        }
    }
    
    // Now add members according
    Foo.prototype.y = function() { /* ... */ };

  • Can't do do partial class in an ambient context, meaning you can't do this in augmentations.

    import { Foo } from "./a";
    
    // Module augmentation.
    declare module "./a" {
        // reopen class
        partial class Foo {
            y() { /* ... */} // Can't do this! The function block of 'y' isn't ambient.  
        }
    }

  • We don't have interface/import merging right now.

• Conclusion: Blocked on unifying syntax & semantics for interface merging.

Inferring new type parameters on arrow functions (#5737)

type Thing = <T>(x: string, c: T) => T;

let x: Thing = (x, foo) => foo;
let b = x("", 32);

Basically want the contextual type of (x, foo) => foo to bless the lambda with a fresh type parameter.
That type parameter is implicit, so there's no way to access it.
Effectively it's an anonymous type parameter.

Report error when base classes haven't been defined (#5794)

👍, be helpful to our users!

Avoid emitting 'var' for every single namespace (#5553)

Resolution: Seems reasonable, 👍

Add .constructor properties of static and instance sides (#3841)

Problem: makes every class ever generic, because it'd use the this type parameter.
This would be a global slowdown for people who might not ever use .constructor.

Issue: static side compatibility checking throws a wrench in here.

Concern: only ES2015 classes have a constructor property on instances.

Resolution: Needs proposal. We need something that doesn't break the world.

Discriminating on iterator yield/return values (#2983)

• You effectively need two discriminated types and two type parameters.
  • But two type parameters mean your existing code breaks.
    • Defaults for type parameters would help this, but it's not clear what the default would be here.

Unresolved.

Allow non-numeric enums (#1206)

Writing this is annoying:

const x = {
    foo: "foo" as "foo",
    bar: "bar" as "bar"
};

People even write

enum E {
    Foo = <any>"foo",
    Bar = <any>"bar"
}

Just for completion support!

What about

enum S {
    someName = "someName",
    foo = "bar"
}

• S is something like "some name" | "bar"
• The static side of S would be something like { someName: "some name"; foo: "bar"; [s: string]: S }.

Conclusion: discuss more seriously offline.

General ideas: never introduce the type S as anything apart from the alias of its member types.