RFC: Generic Constraints

[Kiiyoko]

Hi! This is an RFC to implement extending generics/constraining generics, like in other languages. This is meant to build upon #50's weakpoints.

Rendered

[aatxe]

Thanks for the RFC! Bounded polymorphism is definitely a feature we are looking to add to Luau going forward, and we're excited to be able to do so as soon as possible. I've left a lot of feedback throughout the RFC, but overall, I think the biggest issues here are problems with the actual syntax being proposed, and the actual RFC itself not doing a good job of exploring options and capturing the design space here.

Here are some things that I think this RFC should be shooting for:

1. We should aim to capture at least a few different viable syntax options for bounded generics, including giving consideration to the idea of separate where clauses. It's often the case in languages with bounded polymorphism that the set of constraints on a type can get very large, and having them all inline with its definition can itself become cumbersome. If this RFC wants to argue that such a thing is unnecessary or that it's worth adding this feature without where clauses, that's fine, but the discussion should be present within the RFC text.
2. We should aim to clearly describe the set of bounds that we are trying to add to generic type parameters. Within the scope of this RFC right now, that is solely subtyping constraints. We should describe that explicitly, and include any additional options listed as either part of the RFC or as alternatives that we are consciously choosing not to incorporate (and with an explanation of why not). Some of these alternatives could include inhabitance constraints, equality constraints, inequality constraints, not-subtyping constraints, etc. They all have different use cases, and we should make an argument for why we are or are not including them.
3. We should aim to capture the design of the feature with simple, clear examples paired with crisp English explanations of the intended behavior. You can work up to your example that relies on two type functions, for instance, by talking about the difference between a function that e.g. takes and returns a union like number | string versus a function that takes and returns a generic type bounded by number | string. This distinction is what actually underlies the problem you're hoping to solve with your use of keyof.

[Kiiyoko]

Hi, thank you so much for the feedback. It has helped a lot in trying to rewrite some sections of the RFC.

1. We should aim to capture at least a few different viable syntax options for bounded generics, including giving consideration to the idea of separate where clauses. It's often the case in languages with bounded polymorphism that the set of constraints on a type can get very large, and having them all inline with its definition can itself become cumbersome. If this RFC wants to argue that such a thing is unnecessary or that it's worth adding this feature without where clauses, that's fine, but the discussion should be present within the RFC text.
2. We should aim to clearly describe the set of bounds that we are trying to add to generic type parameters. Within the scope of this RFC right now, that is solely subtyping constraints. We should describe that explicitly, and include any additional options listed as either part of the RFC or as alternatives that we are consciously choosing not to incorporate (and with an explanation of why not). Some of these alternatives could include inhabitance constraints, equality constraints, inequality constraints, not-subtyping constraints, etc. They all have different use cases, and we should make an argument for why we are or are not including them.

This was incredibly important feedback; I have expanded upon where clauses signficantly, and they should allow even more constraints to exist with the way that these constraints are set up.

3. We should aim to capture the design of the feature with simple, clear examples paired with crisp English explanations of the intended behavior. You can work up to your example that relies on two type functions, for instance, by talking about the difference between a function that e.g. takes and returns a union like number | string versus a function that takes and returns a generic type bounded by number | string. This distinction is what actually underlies the problem you're hoping to solve with your use of keyof.

I have added a few examples of this. Thank you so much for the direction.

And overall, I am very sorry for my vocabulary when writing the RFC. I have read through the documentation for Luau quite a bit and I'm surprised that I mixed up & and |. If you have any other commentary I would love to hear it.

[alexmccord]

Two comments:

Firstly, generic bounds has direct consequences with lack of reexports. Suppose you have export type Foo<T> = T in a module, and you decide to update it to export type Foo<T: string> = T. This now requires you to update all reexports variation of Foo, and all type functions that depends on Foo.

This is drastic, since that means you have N * (M1+...+Mi) amount of aliases and functions to update where N represents the number of modules along the reexport chain, and M1+...+Mi represents the sum of type aliases and functions that depends on Foo. This program exists because of the lack of good reexport story.

Obviously, this problem is orthogonal to this RFC, but I think it deserved to be raised to perhaps motivate the story of reexports.

Secondly, I noticed the lack of scoping rules in generic bounds. Type inference is by design unordered to reach fixpoint, so scoping rules generally does not care about the ordering of aliases, I think this should also extend to type parameters too, that is: <r: add<a, b>, a, b>(a, b) -> r is just as valid as <a, r: add<a, b>, b>(a, b) -> r as it is to <a, b, r: add<a, b>>(a, b) -> r.

^{btw you can write git switch -c branch-name}

[alexmccord]

Suggested change

	Type interference believes that either value could be a number or string as `keyof<T>` is a union type of either foo or bar.
	Type inference believes that either value could be a number or string as `keyof<T>` is a union type of either foo or bar.

[alexmccord]

"Treat the generic parameter as a variable--annotate it as declaring a new variable."

It actually is a variable, but it ranges over types instead of values, so X: T is a natural consequence from that.

[alexmccord]

Suggested change

	The `add` function would only accept `T` and `K` if `add<T, K` is not `never`. This is currently available in Luau, but this behaviour is locked behind `add<T, K>` being the return type.
	The `add` function would only accept `T` and `K` if `add<T, K>` is not `never`. This is currently available in Luau, but this behaviour is locked behind `add<T, K>` being the return type.

[alexmccord]

It's a bit hard to do this. A counterexample:

function f() -- f : () -> number | vector
  return if math.random() > 0.5 then 5 else vector.create(0, 0, 0)
end

sumSpecific(f(), f())

Which would still infer T to be number | vector, and provide a number for a and vector for b.

[alexmccord]

Suggested change

	return a + b
	return a * b

[alexmccord]

So if we look closer, we can see that (assuming return a + b was meant to be return a * b) the function multiply's return type would be inferred as mul<T, K>, which is covariant and all its dependent type variables are contravariant: this renders mul<T, K> in the where clause to be redundant. That is, the example is equivalent to

Suggested change

	local function multiply<T, K where T: number, mul<T, K>>( a: T, b: K )
	local function multiply<T, K where T: number>( a: T, b: K ): mul<T, K>

[alexmccord]

Negation types! :)

[Wunder-Wulfe]

I am also curious due to the potential for constraints which are bound by another generic. Here is an example:

--- Negate the current type (since (not T) / (~T) are not yet fully implemented)
type function isnt(T)
    return if T:is"negation" then T:inner() else types.negationof(T);
end

type Vectors = (Vector2 | Vector3);

local function mix<
    T: Vectors | Color3 | UDim2 | CFrame | number, -- accept the following arguments to interpolate between
    U: (number | T) & isnt<CFrame> -- alpha can be scalar, or same type as the argument (except for CFrame) 
>(a: T, b: T, alpha: U): T
    -- this allows for the following legal calls:

    -- <Vector2, number>()->Vector2
    -- <Vector2, Vector2>()->Vector2

    -- <Vector3, number>()->Vector3
    -- <Vector3, Vector3>()->Vector3

    -- <UDim2, number>()->UDim2 
    -- <UDim2, UDim2>()->UDim2 

    -- <Color3, number>()->Color3
    -- <Color3, Color3>()->Color3

    -- <CFrame, number>()->CFrame

    -- <number, number>()->number
end