Generic Inference

[lerno]

Generic inference has 3 possible implementations:

1. fn void foo(Type[] a, Type b) <Type> { ... } implicit inference according some order
2. fn void foo(%Type[] a, Type b) <Type> { ... } implicit inference with explicit guide. In this example, the type on a guides it.
3. fn void foo(Type[] a, Type b) <Type = $Typeof(a[0])> { ... } explicit inference rules.

[lerno]

(1) For this, only a best-attempt may be done. For example something like List{Type} a might be too complex to infer. There is a danger that inference rules may be tempting to upgrade in "better" compilers. But this has to be locked to work the same way always or there will be inconsistent results. There is also a temptation to only allow simple inference, like foo(Type a), but that will do away with possibly other simple solutions. For user friction this is minimal though, even though things like foo(Type a, Type b) might be problematic if we only infer from a, when it might be better to infer from the max of the types. This could also be done of course, at the cost of increasing complexity. The problem comes when we do "max" of the type even when it's unintended.

[lerno]

(2) This is similar to (1), but we use some sigil or other marker to guide the inference. This gives better control, but complexity is essentially the same as (1). Odin uses this.

[lerno]

(3) This is a bit novel and has a little more friction, but is best-in-class inference. The idea is to create a "default" expression, derived from the parameters:

fn void foo(Type[] a, Type b) <Type = $Typeof(a[0])> { ... }

However, this initial syntax is flawed. In particular > here makes it ambiguous. A better syntax would be:

fn void foo(Type[] a, Type b) [Type = $Typeof(a[0])]
{
  a[0] = b;
}

Note now that this would require changed generic syntax. Since $Typeof almost always appear we could elide that:

fn void foo(Type[] a, Type b) [Type = a[0]]
{
  a[0] = b;
}

And maybe = isn't ideal, so then we get:

fn void foo(Type[] a, Type b) [Type: a[0]]
{
  a[0] = b;
}

Let's say we do a a + b and we want the types inferred to be the result type, we then get:

fn Type add(Type a, Type b) [Type: a + b]
{
  return a + b;
}

The downside of this shorthand is that we don't have the $Typeof. But we could make = yield that. So the equivalent of the above is:

fn Type add(Type a, Type b) [Type = $Typeof(a + b)]
{
  return a + b;
}

In case of multiple arguments, all must be inferred or none, anything else is confusing.

[lerno]

Because these are linked to functions, they need to be specified on each function, since each function is different. Note that even if a function is in a module with a generic type Type, it would need to be repeated for the inference to be added, creating some redundancy in case (3)

[lerno]

Feedback is very welcome.

[lerno]

Alternatively, we promote macros instead and add @noinline which basically turns the macros into functions on demand. This makes generics more for types.

[EroMrinin134]

I guess we firstly shall list all relevant "strategies" of generic inference, like

• taking type of spesific parameter (Type a, Type b -> Type = $Typeof(a))
• taking "bigger" type (Type a, Type b -> Type = $Typeof(a + b))
  ...
  As I can see, if there's small number of strategies then one can be implicit and others would need attributes:
• (Type a, Type b) -> a is defines Type because a is the most left
• (Type a, Type b) @infer_bigger(Type)
  ...

[lerno]

@EroMrinin134 here is an example which has more complexity:

fn Type2 sub(Type1 a, Type1 b) [Type1: a, Type2: a - b] => a - b;

Now use sub(&x, &y).

Another:

fn Type2 get(Type1 a) [Type1: a, Type2: a.foo()] => x.foo();

[EroMrinin134]

Is there any situation where inference require explicit $Typeof? Because [Type: some_expr()] seems promising currently.
Only obvious downside if grouping will be added and we'll get [group_name: Type: some_expr()] which isn't looking nice.

[EroMrinin134]

Proposal: [Type (group_name): a+b]

[lerno]

How do you envision that with something like <Type, FOO, Type2> @EroMrinin134

[EroMrinin134]

How do you envision that with something like <Type, FOO, Type2> @EroMrinin134

[Type (group_1): a, FOO, Type2 (group_2): b+c]

[lerno]

Wait, I thought you meant "group" to handle the grouping. A generic will only belong to one group.

[EroMrinin134]

Wait, I thought you meant "group" to handle the grouping. A generic will only belong to one group.

I am about grouping - I've thought that diffrent generic params may have different groups (missed a note in the issue).
Then we may have: [group_name; Type: a, FOO, Type2: b+c]