Replace Option<T> with ? in ListK (part 1)

[tapegram]

Part 1 of providing alternatives for fns that use Option for ListK.

Ran into https://discuss.kotlinlang.org/t/overloaded-function-with-lambda-parameter-of-different-return-types/6053/2 when creating a nullable version of filterMap, so I gave the nullable one a different and less good name :(

Would especial appreciate any feedback on the naming of these functions, since the older Option based functions already have the good names and the type system struggles to handle overloading with generics or lambdas without requiring explicit typing by the consumer, so I had to make up new names when required.

[nomisRev]

Oh, that sucks :( This should be fixable with @BuilderInference, but that's still experimemtal isn't it?

[nomisRev]

The namings used here look good to me! 👍

I see a lot of the names involve recent contributions by @1Jajen1 and @abendt.

[nomisRev]

Should we do? We're also trying to algining more to the names familiar in Kotlin from the std. IIRC there is 2 Iterable extensions for the signature in the std. filterMap and mapNotNull?

@JvmName("mapNotNull")
fun <B> filterMap(f: (A) -> B?): ListK<B>

[1Jajen1]

I think as long as the stdlib ones don't have any obvious drawbacks we shouldn't have duplicates names and signatures.

[nomisRev]

In that case I think we should name it mapNotNull as Kotlin's Std?

We can re-introduce filterMap if we want later on.

[1Jajen1]

👍

[nomisRev]

I think filterNullMap should renamed to mapNotNull to be inline with Kotlin's Std.

Thanks for the contribution @tapegram! 🙌 🎉

[nomisRev]

In that case I think we should name it mapNotNull as Kotlin's Std?

We can re-introduce filterMap if we want later on.

[aballano]

Just some nits, overall looks good!

[nomisRev]

Thanks so much @tapegram for the contribution!