Add optional.unwrap() / .unwrapOpt() function

[seirl]

This function takes a list of optional values and only returns the non-none values from the list, skipping the none values, and returning a list of the unwrapped values directly.

[TristonianJones]

@seirl we ended up choosing a different name for this feature, with optional.unwrap in the cel-java repo: google/cel-java#438

I think the behavior is the same, but would you mind taking a look and updating to match?

[seirl]

Ah, okay. I think it might hinder readability in our case, because we usually have long chains of map/filter/flatten/elideOpt/all/exists/....
The fact that all of these are postfix except optional.unwrap() is going to make it less readable, as readers will have to go back and forth in the line.
Is this still something that could be changed or is it too late?

[TristonianJones]

Hi @seirl, my impression is that the chains will continue to work just fine, but you'd probably just want to wrap the end result into an optional.unwrap to make sure a non-empty list of values is produced. A few examples might help in the event that I'm misunderstanding the use case.

[seirl]

The problem is that mixing up prefix and postfix is less readable in long processing chains:

mylist
  .sortBy(foo, foo.bar)
  .elideOpt()
  .filter(x, x.value < 42)
  .elideOpt()
  .flatten()

vs:

optional.unwrap(
  optional.unwrap(
    mylist
      .sortBy(foo, foo.bar)
  ).filter(x, x.value < 42)
).flatten()

(which I had to re-read 3 times to make sure that it was correctly parenthesized)

So my preference is for postfix because it's the most consistent, but we could also have both for backwards compatibility (one prefix and one postfix, maybe .unwrapOpt()?).

[TristonianJones]

Consider, for a moment, that the expression mylist.sortBy(foo, foo.bar) won't work since optionals are not comparable, nor would a filter expression work when the list is not already flattened.

My impression of what you're actually going to have to support is something more like the following:

optional.unwrap(mylist).sortBy(foo, foo.bar).filter(foo, foo.value < 42)

That is to say, I expect the unwrap to typically happen at the beginning or end of an expression chain. If there are more examples of when we might perform intermediate computations, I'm willing to consider a chained unwrap which takes a list target value.

[seirl]

Right, sorry! Here is a more realistic example partially taken from our codebase:

lists.range(size(foo.target))
  .filter(i, foo.target[i].?attr.?attr.orValue("").startsWith("/foobar/"))
  .map(i, foo.qux[i])
  .elideOpt()
  .sortBy(x, x.blah)
  .distinct()

[TristonianJones]

@seirl thank you, that helps me better understand. In that case, to be consistent, let's introduce optional.unwrap (namespaced method) and <list(optional(T))>.unwrapOpt() -> list(T)

[seirl]

@TristonianJones PTAL :-)