Allow object types to have property-like associated types

[dead-claudia]

Edit: Add static Type variant for classes, make abstractness a little clearer, clarify things.

This has probably already been asked before, but a quick search didn't turn up anything.

This is similar, and partially inspired by, Swift's/Rust's associated types and Scala's abstract types.

---

Rationale

• In complex structures like in virtual DOM components/nodes and in graphs, where there are numerous constraints to check, but they would get cumbersome in a hurry to force off onto the user.
• In dynamic imports, where you never have the module namespace itself until runtime, yet you still want to be able to use types defined within it. Edit: Already addressed elsewhere.
• In types where there's a lot of optional parameters, it'd be easier and more flexible to label which ones you're defining as part of the type.
• In types where you want to specify a single optional parameter, and the required ordering requires you to specify some that you don't want to specify, that would get boilerplatey in a hurry. I've experienced this personally on multiple occasions.
• It would allow fully typing namespaces and named module imports without hard-coded compiler handling.

Proposed Syntax/Semantics

• Each interface and object type may have a number of associated types within it.
• Associated types are checked for assignability like any other usual property, except they live in a different "namespace" from properties. In particular, the type must be assignable to the target's type.
• To access an associated type, you use TypeName.Type, where Type is the name of an associated type.
  • For sugar and namespace compatibility, object.Type is equivalent to (typeof object).Type
• To expect an interface with an associated type, you use Foo & {type Type: Value} or Foo with <Type: Value>.
• To expect an object with an associated type, you use {type Type: Value}.
• To declare an abstract associated type, you use type Type: * within the interface or object type.
• To declare a non-abstract associated type, you use type Type: Default within the interface or object type.
• To constrain an abstract associated type, you use type Type: * extends Super.
• Associated types may be inherited from other interfaces and/or object types.
• Namespaces' types are modified to include the exported types as associated types.
• Classes may also define associated types, optionally with visibility modifiers.
• Associated types may have defaults, in case they aren't defined or further constrained later.
  • Constraining an associated type with an existing default removes the default if and only if the existing constraint is not assignable to the new constraint. For example, {type Foo: string | number = string} & {type Foo: string | number} is assignable to {type Foo: string}, but {type Foo: string | number = string} & {type Foo: number} is not.

Here's what that would look like in syntax:

// Interfaces
interface Foo {
    type Type: *; // abstract
    type Sub: * extends Type; // abstract, constrained
    type Type: Default;
    type Type: * extends Type = Default; // late-bound default
}

// Objects
type Foo = {
    type Type: Foo,
}

// Classes
abstract class Foo {
    // Note: outer class *must* be abstract for these, and the keyword is required.
    abstract type Type: *; // abstract
    private abstract type Sub: * extends Type; // abstract, constrained
    protected abstract type Type: * extends Type = Default, // late-bound default

    // Note: outer class *may* be not abstract for these.
    type Type: Default;
    private type Type: Default;

    // Declare an associated type in the class
    // Note: type must not be abstract.
    static Type: Foo;
}

Emit

This has no effect on the JavaScript emit as it is purely type-level.

Compatibility

• This is purely additive, making no observably incompatible changes beyond possibly different error messages.
• This has no impact on any existing JavaScript-related proposal.

Other

• It may slow down the type checker a little initially when namespaces are unified, but two optimization points are available, which would recover most of the perf hit, if not all:
  • Associated types could be stored in a per-interface type map.
  • The list of associated types could be initially stored as undefined to avoid generating a large number of empty arrays.
• It should have little effect on editor tooling.

[RyanCavanaugh]

Can you show a few small examples of how the motivating cases get solved using this proposal?

[dead-claudia]

@RyanCavanaugh

Edit: Be a little more rigorous with typing, update per proposal revision

I just did a little more searching and found that this is effectively a more detailed dupe of #9889, but using less ivory-tower terminology. But anyways...

Here's an example for a theoretical vnode structure based on Mithril's, demonstrating both :

// Note: I've specifically removed the fragment-related types and some of the
// more specific constraints for simplicity

export type VNode = DOMVNode<Attributes> | ComponentVNode<Component>;

interface _Lifecycle {
	type VNode: * extends VNode;
	type State: this;

	oninit?(this: this.State, vnode: this.VNode): void;
	oncreate?(this: this.State, vnode: this.VNode): void;
	onbeforeremove?(this: this.State, vnode: this.VNode): Promise<any> | void;
	onremove?(this: this.State, vnode: this.VNode): void;
	onbeforeupdate?(this: this.State, vnode: this.VNode, old: this.VNode): boolean | void;
	onupdate?(this: this.State, vnode: this.VNode): void;
}

export interface Attributes extends _Lifecycle {
	type VNode: DOMVNode<this>;
	type Attrs: this;
	type ChildType: Children;
	type Element: * extends Element = HTMLElement;
}

// Children types
export type Child = ...;
export type Children<T extends Child = Child> = ...;

interface _Virtual<T extends string | C, C extends Attributes | Component> {
	tag: T;
	attrs: C.Attrs;
	state: C.State;
	children: C.ChildType;
	dom: C.Element;
}

interface DOMVNode<A extends Attributes> extends _Virtual<string, A> {}
interface ComponentVNode<C extends Component> extends _Virtual<C, C> {}

export interface ComponentAttributes<C extends Component> extends _Lifecycle {
	type VNode: ComponentVNode<C>;
}

export interface Component extends _Lifecycle {
	type Element: * extends Element = HTMLElement;
	type Attrs: ComponentAttributes<this>;
	type ChildType: Child;
	type VNode: ComponentVNode<this>;

	view(this: this.State, vnode: this.VNode): Children;
}

// Later:
export const Video = {
    type Element = HTMLVideoElement,
    type Attrs: ComponentAttributes<this> & {
        [P in keyof HTMLVideoElement]: T[P]
        playing: boolean
    },
    type State = this & {playing: boolean},

    oninit() { this.playing = false },
    oncreate(vnode) { if (this.playing) vnode.dom.play() },
    onupdate(vnode) {
        const playing = !!vnode.attrs.playing
        if (playing !== this.playing) {
            this.playing = playing
            if (playing) vnode.dom.play()
            else vnode.dom.pause()
        }
    },

    view(vnode) {
        const attrs = {}
        for (const key in Object.keys(vnode.attrs)) {
            if (key in HTMLVideoElement) attrs[key] = vnode.attrs[key]
        }
        return m("video", attrs)
    },
}

It's kind of hard to create a small, compelling example, because it only really starts showing its benefits with more complex types. Here's a few notes:

• Associated types allow limited encapsulation of their outer types. You may notice that ComponentType is not actually generic. That's because you the user don't want to have to repeat what attributes it takes, what children it requires, etc., but you the implementor do care that your component receives the attributes and children you expect.
• Associated types allow types to be considered as part of the interface, rather than part of the parent type. If you expect a type-like value (like Mithril's object components), you want to ensure that internally, your types remain correct. Each component and attribute map have a particular type of vnode they use to model their rendered state, so you want to ensure it remains true to their type.
• Associated types allow some non-local passage that rely on this, offering a workaround for Polymorphic this and Generics #6223 for some common cases, with a little boilerplate. You may notice that _Lifecycle uses associated types rather than parameters, but that's because otherwise, I'd require this to be available in the extends clause, like extends _Lifecycle<this, VnodeComp<this>>.

---

Also, here's some clarifications/corrections to the original proposal:

• Associated types without constraints implicitly default to any.
• Object literals may also include type aliases inline.
• An object type with only associated types is not considered a weak type provided at least one of them has no default.
• The outer interface, of course, can't extend any of its associated types.
• The types are late-bound, almost like a restricted existential. (Scala uses abstract types and generics to cover most of the need for existentials.)
• To set named types without Type & {type Foo: Bar}, you use Type with <Foo=Bar>, not Type<Foo=Bar> (to make it work with type aliases). It also requires that such an associated type exists, unlike Type & {type Foo: Bar}.
• Type & {type Foo: Bar} and Type with <Foo=Bar> are equivalent, but Type & {type Foo: this.Bar} and Type with <Foo=this.Bar> are not.
• Associated types may not be accessed from the interface itself, actually. They may only be accessed via the values.

[weswigham]

You can do this today, right now, with indexed access types (to steal what you have).

It's not 100% the same, because there are some ergonomic differences and there were some type errors when I just changed the syntax, so it's a bit different because I'm unsure what you were going for. Hopefully you get the gist of it - indexed access on generics (like this) is related types. The only difference is that we assume that there must be value-space members for each 'psuedo-related type'.

[masaeedu]

It seems a more principled approach to this would be to support type families, which are type-level partial functions. These allow you to express arbitrary relations between types.

Instead of adding new syntax like InterfaceName.Type, you continue doing Type<InterfaceName> to retrieve an "associated type", but Type is a full-fat type-level function (i.e. supports overloading), which means Type<InterfaceName, "foo"> can resolve to a different thing from Type<Foo>, which can resolve to a different thing from Type<number>.

[dead-claudia]

@weswigham

The key differences are that:

1. Types are required to be present, unlike optional indexed types like in your playground gist.
2. The syntax opens the door for future generic associated types, which is where it gets far more powerful (as in, up there with OCaml's module functors), and would also add support for higher-kinded types. I just didn't include it in the original proposal, so it could start a bit smaller in scope.

To give an example of the second, using Fantasy Land's Monad type:

interface Monad {
    type T<A>: any;

    map<A, B>(this: this.T<A>, f: (a: A) => B): this.T<B>;
    ap<A, B>(this: this.T<A>, f: this.T<(a: A) => B>): this.T<B>;
    of<A>(a: A): this.T<A>;
    chain<A, B>(this: this.T<A>, f: (a: A) => this.T<B>): this.T<B>;
}

[dead-claudia]

@weswigham I also made a few tweaks to my proposal, which should help clarify things some. Try re-attempting it now with my revised example.

[dead-claudia]

@masaeedu Technically, this is looking for an implementation of type families; I'm just referring to the inner types (which are associated types) rather than the outer enclosing interface (type family).

Edit: to clarify, interfaces can be made polymorphic, and that's how you get a full implementation of type families. Consider this:

{-# LANGUAGE TypeFamilies #-}
class GMapKey k where
    data GMap k :: * -> *
    empty       :: GMap k v
    lookup      :: k -> GMap k v -> Maybe v
    insert      :: k -> v -> GMap k v -> GMap k v

Here's an equivalent implementation of this using my proposal:

interface Map<K> {
    type To<V>: *;
    
    create<V>(value: V): this.To<V>;
    empty<V>(): this.To<V>;
    lookup<V>(key: K, map: this.To<V>): V | void;
    insert<V>(key: K, value: V, map: this.To<V>): this.To<V>;
}

[masaeedu]

@isiahmeadows Ok, so it seems like the disagreement is mostly syntactic then. Do you think something like #17636 would be an alternative that would satisfy your requirements?

[dead-claudia]

@masaeedu That issue concerns a completely different problem: that of mapped types not having significant utility without some sort of filtering mechanism.

[masaeedu]

@isiahmeadows That issue provides type families in the sense of Haskell: type-level overloaded functions of an arbitrary arity of type arguments.

For your use case, you can have an entire family of indexed types described by FooAssociate<"thing1">, FooAssociate<"thing2">, FooAssociate<"thing3"> returning all the associated types of Foo. You'd declare it as type FooAssociate<T extends "thing1"> = ..., etc.

[dead-claudia]

@masaeedu Still, it's a hack that really misses the other problem I'm attempting to tackle with this issue: type encapsulation. Consider that in complex-to-model types, the number of generic parameters can get unwieldy enough that you find it easier to skip out on the types somewhat. Just as an example, imagine if this used your proposal instead of mine - feel free to try to port it to yours, and compare. You'll notice very quickly what I mean.

[masaeedu]

@isiahmeadows It isn't so much a hack as a strict generalization of associated types. Quoting the Haskell wiki page on type families where the GMapKey example originates:

Data families appear in two flavours: (1) they can be defined on the toplevel or (2) they can appear inside type classes (in which case they are known as associated types). The former is the more general variant, as it lacks the requirement for the type-indices to coincide with the class parameters.

At the very least we shouldn't implement the special cased sugar without the fundamental concept.

Just as an example, imagine if this used your proposal instead of mine - feel free to try to port it to yours, and compare.

Unfortunately there's too much stuff going on in that example for me to be able to understand what it represents (maybe the problem is I'm unfamiliar with Mithril). However, a crack at explaining how VNode would work from what little I understand:

type VNode<T extends Attributes> = DOMVNode<T>
type VNode<T extends ComponentAttributes<C>, C extends Component> = ComponentVNode<C>
type VNode<T extends Component> = ComponentVNode<T>

// Wherever you actually need it: VNode<this>, VNode<FooComponent>, VNode<typeof etc.>

[masaeedu]

The snippet above also illustrates an interesting design aspect: encapsulation breaks DRY. The second overload: type VNode<T extends ComponentAttributes<C>, C extends Component> = ComponentVNode<C>, is actually redundant with this formulation. It is already covered by type VNode<T extends Component> = ComponentVNode<T>.

Similarly, this approach does not permit associating arbitrary types with types for which you have no control over the declaration. I can't just associate types with Array unless I have control over Arrays declaration; I must instead make a subtype using extends and put the associated type there, then conscietiously use MyArray everywhere.