mapNonNull and filterNonNull leave nullable types intact

[viert]

Hi team,

mapNonNull and filterNonNull should presumably change the resulting type from Listing<Elem?> to Listing<Elem> as the result is guaranteed to not have nulls. The warning is misleading and requires a redundant as Listing<Elem> extra.

[holzensp]

Yes, this is a known issue. For mapNonNull, this should actually be doable. For filterNonNull there's a Hard Problem™ to solve. What you're seeing here is that static type analysis that only happens in the plugin (not the interpreter). It does this by taking the type signature as specified.

For mapNonNull, we could change the type from

mapNonNull<Result>(transform: (Element) -> Result): Collection<Result(this != null)>

to

mapNonNull<Result>(transform: (Element) -> Result?): Collection<Result>

(and similar for List and Set)

The downside of this is that it becomes a type mismatch when the plugin can't explicitly decide that your transform results in a nullable Result (this happens disappointingly more often that you might think). That would mean it explicitly requires as MyType? asserting.

For filterNonNull, the only route I can see is special-casing it in the plugin, because the type is

filterNonNull(): Collection<Element(this != null)>

(and similar for List and Set)

To use the specified type signatures for that, Pkl would need to support something like Generic Where Clauses in Swift (similar; conditional methods in C#), because, as you can see, the definition of Element lives on the class, not on the method's signature.