Add list flatten()

[fabriziosestito]

Adds list flatten, fixing #352

[flavio]

Looks pretty neat, thanks!

[seirl]

Is there a reason to make this recursive by default? The common case is to flatten a list of list. I feel like a recursive flatten would better be a separate .flattenRec() function.

[fabriziosestito]

@seirl I took inspiration from Elixir's List.flatten.
Also, Ruby's Array.flatten is recursive by default, but it accepts an optional level argument. We could consider this behaviour, as it is more flexible.

However, I don't have a strong opinion and I am ok with what you proposed.

[seirl]

Interesting. FWIW:

• in Rust, std::iter::Flatten flattens a single level.
• in Python, itertools.chain() flattens a single level.

The reason I'm mentioning this is because flatten could also be useful to flatten a list(optional(T)) into a list(T), but the semantics are more complex if you have a recursive flatten.

[fabriziosestito]

@seirl Alright, I will change this to single-level flattening.

[fabriziosestito]

@seirl I've followed your suggestion, now flatten flattens to a single level, while flattenDeep flattens recursively. I've preferred the deep naming as I find it clearer for the user and it is also used by lodash.

[TristonianJones]

/gcbrun

[TristonianJones]

/gcbrun

[TristonianJones]

Thank you for the update. I've added a few comments on how to structure this so it's safer for production rollout and works with cost estimation tools!

[TristonianJones]

/gcbrun

[TristonianJones]

I'll update the signature of single-level flatten post-merge. Thanks for the contribution and the patience!

[fabriziosestito]

@TristonianJones, thank you for merging. I'm currently on vacation with limited laptop access. I'll handle the cost estimation if the task is still open when I return. Regarding the function signature, shouldn't it be something like flatten<T>(list(T | list(T))) -> list(T)?

[seirl]

@fabriziosestito the one-level .flatten() should only flatten List[List[T]], so [1, [2, 3]].flatten() should be an error.

If you use only strongly-typed CEL, all your lists need to be homogeneous, so [1, [2, 3]] doesn't make sense as a value.

[TristonianJones]

@seirl I took care of the signature change in a different PR. The test case will pass checking because the mixed type list is list(dyn)