Allow count of elements in repeated-element array syntax to be any `comptime Field`

[jfecher]

Problem

PR #440 expands the repeated-element array syntax to accept a count of elements where count is an integer expression containing only literals, basic numeric operations, or global constants. Although this should cover most usecases, it is theoretically overly limiting to users.

Solution

We could allow all expressions that evaluate to a comptime Field (or other countable integer type) as part of the count expression. Then both expressions in [expr; expr] would be arbitrary, just with type checking constraints limiting the second to be known at compile-time.

Alternatives considered

Alternatively, we could say users do not need this flexibility and choose not to have this feature.

[kevaundray]

@f01dab1e feel free to take this on; if you choose to, please write a summary of how you plan to take it on in this issue beforehand

[ghost]

should we start introducing the concept of const? and allow only const expressions?

[jfecher]

Right now, it seems like the main thing we're missing is the ability to use numeric generics in these array size expressions. I don't think we'd need full const expression support (e.g. const functions), we should start with this main missing feature I think.

[ghost]

I was asked to write a plan...

introduce a new type: AbstractConst, something like this:

struct AbstractConst {
    nodes: Vec<Node>,
}

enum Node {
    Leaf(u64 | Param),
    Binary(Node, BinOp, Node),
    Unary(UnOp, Node),
}

expand unification with the try_unify_const function. something like this:

fn try_unify_const(a: AbstractConst, b: AbstractConst) -> bool {
 match (a.root(), b.root()) {
     (Leaf(a), Leaf(b)) => a == b,
     (UnaryOp(a_op, av), UnaryOp(b_op, bv)) if a_op == b_op => {
         try_unify_const(a.subtree(av), b.subtree(bv))
     }
     <...>
 }
}

when the user supplies type parameters with values it is easy to execute...