Closed fabriziosestito closed 3 weeks ago
@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.
Interesting. FWIW:
std::iter::Flatten
flattens a single level.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.
@seirl Alright, I will change this to single-level flattening.
@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.
/gcbrun
/gcbrun
/gcbrun
@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)
?
@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.
@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)
Adds list flatten, fixing #352