I don't see anything here you can't already do today, with the same ergonomics, with generics.

For example, you could default the generic and bundle up any abstract members into a container type so there's only ever one type argument:

class Base<T extends { a: unknown, b: unknown } = any> {
    connect(arg1: T["a"], arg2: T["b"]) {

    }
}

class Derived extends Base<{ a: string, b: number}> {

}

const m = new Derived();
m.connect("hello", 42);

// References to the generic type are unneeded
function f(b: Base) {

}

The only thing that's missing here for 100% fidelity to your suggestion is local type aliases in the class body, which is a separate suggestion.

Derived is not forced to provide types for a and b though, in this setup, is it: this isn't the same as what I've suggested.

Consider what happens if I change a to type string:

class Base<T extends { a: string, b: unknown } = any> {
    connect(arg1: T["a"], arg2: T["b"]) {
        console.log(arg1.toLowerCase())
    }
}

Base compiles; toLowerCase() is a method on string.

This compiles too, though:

class Derived extends Base {

    constructor() {
        super()
        this.connect(42, "hello")
    }
}

Defaulting the generics to any via their omission strips the type checking. With an abstract type member the subclass cannot be compiled unless it provides a valid type.

If those are the only deficits relative to what's currently available, then this isn't meeting the value-vs-complexity bar.

What does the "Too Complex" label refer to? Your estimation of the internal changes required to implement this?

All forms of complexity: Implementation, cognitive load for people learning the language, overall code size, chances of constraining future development, performance, total code size of the compiler, time to run our test suites, odds that we interfere with future TC39 syntax, etc... See also https://gist.github.com/stuartd/a100fb315f2e5ca9ed17551d8b538a60

Ok. There seems to be a fair amount of subjectivity in that assessment. Squaring off "time to run our test suites" versus the usefulness of the feature to future users is not a piece of maths you could possibly do empirically, for instance. There must be a certain element of personal opinion in a judgement like that. Of course it's informed opinion from someone who's been close to the project for years so it's bound to be of more utility than that of someone who has just arrived. I understand the sentiment in the linked post; people are always asking me to add various kitchen sinks to jsPlumb and I reject many of the suggestions for the same reasons discussed there. I wouldn't have suggested this for Typescript if I didn't genuinely think it would be of use.

Don't take this the wrong way, but the generic based solution you suggested was like someone telling me I could open a tin can with a knife. It's a good party trick, but messy, and shot through with ways to go wrong.

I intend to work on this on a fork anyway as it will be an interesting learning experience working through the code. And then I'll also be able to get an answer, at least for myself, to the questions of how much bigger the compiler is, how much longer the tests take to run, etc. I won't close this issue, though. That would be like giving up. You can close it if you like ;)

I think experimentation is always encouraged, as long as the expectations are clear. It's not that our team hasn't changed our minds about different design suggestions, but we can't guarantee that we'll merge PRs even if the work's already done.

Yes that's cool, I have no expectations that if I continue on with it the end result could get merged. It's an interesting problem for me to tinker with anyway.

I came here searching for something similar to C++'s "member typedefs" (https://riptutorial.com/cplusplus/example/14397/member-types-and-aliases)

1. Why must it be abstract? Can we just treat it as normal members, so they can be overridden in derived types, and can also be abstract in abstract classes?
2. If it's allowed to access these "type members" from outside the class? Via Buffer["T"] or other syntax?

My use case:

I have some very complex generic classes, and methods on them returns some other very complex generic types.

As a simplified example, let's take a look at the built-in Iterator interface:

interface Iterator<T, TReturn = any, TNext = undefined> {
    // NOTE: 'next' is defined using a tuple to ensure we report the correct assignability errors in all places.
    next(...args: [] | [TNext]): IteratorResult<T, TReturn>;
    return?(value?: TReturn): IteratorResult<T, TReturn>;
    throw?(e?: any): IteratorResult<T, TReturn>;
}

If I already have a declare const iterator: Iterator<number, void, void>, and I want to declare a variable that can accept results from iterator, now there are several ways to achieve this goal:

1. let result: IteratorResult<string, void>;. Problems:
   1. I need to check Iterator's type declaration so I know its result type is called IteratorResult
   2. I must repeat all generic parameters
2. let result: ReturnType<typeof iterator["next"]>. Much better, but still tied to a specific function, adds some extra mental overhaul
3. (the workaround I'm currently using)

   interface Iterator<T, TReturn = any, TNext = undefined> {
       TResult: IteratorResult<T, TReturn>;
       // NOTE: 'next' is defined using a tuple to ensure we report the correct assignability errors in all places.
       next(...args: [] | [TNext]): this["TResult"];
       return?(value?: TReturn): this["TResult"];
       throw?(e?: any): this["TResult"];
   }
   
   let result: typeof iterator["TResult"];

Problems:

1. TResult is a field, but it only represents a type, won't have any value. But there is no constraint to use it as a value.

Difference from merging interface with namespace:

Another similar feature we already have is merging an interface declaration with a namespace:

interface Foo {
    value: Foo.Bar;
}

namespace Foo {
   type Bar = string;
}

type BarAlias = Foo.Bar;

It "looks alike" Bar is a member of Foo, and we use dot (.) to access Foo.Bar.

However namespaces can't be generic, thus an advantage of this proposal is that we can declare "type members" within generic types, and those "type members" should be able to use all generic parameters on the containing type.

interface Foo<T> {
    type Bar = T; // temporal syntax
    value: Bar; // temporal syntax
}

type BarAlias = Foo<string>.Bar; // temporal syntax

declare const foo: Foo<string>;
type BarAliasFromInstance = (typeof foo).Bar; // temporal syntax

Some other advantages:

1. Like in my Iterator example workaround above, all three methods can reuse the same type, the code gets cleaner, and if one day the result type need to be changed, only one location requires modification.
2. Type consumers can use these types more comfortably, without caring about internal implementations and future API changes.

@yume-chan To answer your questions:

1. Why must it be abstract? Can we just treat it as normal members, so they can be overridden in derived types, and can also be abstract in abstract classes?

I would actually re-write my original suggestion to be this now:

abstract class Core {
    type T
}

class BrowserInstance extends Core {
    type T = HTMLElement
}

the difference being that abstract should not be required as a modifier on type T in class Core - the omission of the type body is sufficient, and this syntax is equivalent to how an abstract value is defined:

abstract class D {
    defineMe:string
}

There's no notion that this be limited to abstract only - the way you have described it, as "normal members" that can be overridden and also abstract, is how I would envisage it working in TypeScript. In @RyanCavanaugh's initial response I think he actually identified what this proposal is: it's simply to add "local type aliases in the class body". But I'd like them to be able to be overridden and to be abstract.

2. If it's allowed to access these "type members" from outside the class? With Buffer["T"] or other syntax?

In Scala you can access a type member from an instance of some class, but not as a static member on that class. For example, given this class:

class A {
  type C = String
  def foo():C = "foo"
}

Type C is not accessible as a value, but it is as a type, for instance:

val a = new A 
val foo:a.C = a.foo()

foo is declared as being of type a.C

Regarding the third code snippet:

declare const foo: Foo<string>;
type BarAliasFromInstance = (typeof foo).Bar; // temporal syntax

BarAliasFromInstance is not in fact a type alias from an instance - you haven't instantiated a Foo here. To model the Scala example I gave above, of a type alias from an instance, in (pretend) code it might be like this:

class Foo<T> {
    type Bar = T
}

const foo = new Foo<string>()
type BarAliasFromInstance = foo.Bar

I must admit that personally I don't see a lot of value in this, in either of the two examples involving a generic type on the class, since the specification of the type parameter has just been made; you might just as well in fact have spun it around and made the code more logical anyway:

type BarAliasFromInstance = string
declare const foo:Foo<BarAliasFromInstance>

Whether there is value in being able to assign a type from a setup that doesn't involve generics:

class Foo {
    type Bar = string
    hello():Bar {
        return "hello"
    }
}

const foo:Foo = new Foo()
const output:foo.Bar = foo.hello()

...is a question for the community at large. As I said earlier, Scala supports it, so perhaps there are use cases. I've not used it myself, but I'm just one guy.

the difference being that abstract should not be required as a modifier on type T in class Core - the omission of the type body is sufficient, and this syntax is equivalent to how an abstract value is defined:

No, In TypeScript you must prepend another abstract modifier to fields you want derived classes to implement:

abstract class Foo {
    fn(): void; // Function implementation is missing or not immediately following the declaration. (2391)
}

abstract class Foo {
    abstract fn(): void; // correct
}

To model the Scala example I gave above, of a type alias from an instance, in (pretend) code it might be like this:

That's interesting.

In C++ you can only access member typedefs using the class itself, not instances.

However they are still considered as "members" of the class, because they require type instantiating:

#include <iostream>

using namespace std;

template <class T>
class Foo {
  public:
    typedef T Item; // <- a simple alias
};

int main()
{
    Foo<string>::Item value = "foo";  // <- I don't need an instance
    cout << value << endl;

    return 0;
}

In TypeScript, current syntax to get a member's type also uses the class name itself:

class Foo<T> {
    value: T;
}

declare const value: Foo<string>["value"];

Requiring an instance to access its members' type can also limit its usage, for example what if I want to use a member type in class declaration:

class A<T> {
   value: T;
}

class B<T> {
   value: A<T>["value"] // my value will always have same type as `A`'s
}

How can I get a variable of A<T> in B<T>?

I must admit that personally I don't see a lot of value in this, in either of the two examples involving a generic type on the class, since the specification of the type parameter has just been made; you might just as well in fact have spun it around and made the code more logical anyway:

In my Iterator<T> example, the member type TResult is computed by an expression, so it's impossible to declare it by yourself without checking its implementation.

Member types can be very complex and should be considered as internal implementation detail of the class, so declare it by yourself is difficult to write, difficult to read, and not future-proof.

No, In TypeScript you must prepend another abstract modifier to fields you want derived classes to implement:

Ah yes, confusing the two languages there. So what I had first was correct, as in, what I wanted to suggest:

abstract class Parent {
  abstract type AcceptableType
}

class Child extends Parent {
  type AcceptableType = string
}

@yume-chan Yesterday I updated jsPlumb to implement the scheme that was suggested to me in the first response to this issue, since for my use case it's definitely better than not having anything at all. While doing so I came across a whole bunch of times that I wanted to be able to reference what would be the type member - and I wanted to do it by referring to the class, not by referring to an instance of the class.

I have a feeling in fact that this class vs instance question might be largely resolved by what's actually possible within the code (without major surgery,) and I haven't actually started to dig around very much yet. But yes, I think my preference also would be to access the type on a class, not on an instance of a class.