heya all, it seems like the latest arrow was missi...

# arrow

[mitch]

heya all, it seems like the latest arrow was missing a few utilities for List<T> -> Option<NonEmptyList<T>> ? was it missed?

Context, I found out NonEmptyList.fromList is now deprecated in favour of nullable types list.toNonEmptyListOrNull() which is quite verbose. In our kotlin projects, we favour Option<T> and we don’t use nullable types, hence now we will need to do a list.toNonEmptyListOrNull().toOption() which is even more verbose.. I wonder if there’s any objections if I raise a PR to introduce list.toNonEmptyListOrNone() ? or a shorter one such as list.toNelOrNone()

[raulraja]

I think that PR would be useful, thanks @mitch, I'm in favor of adding that method under the basis that if we provide Option we should support it in the same way we do with nullable types. Having said that we only recommend people use Option in those cases where you are doing interop with a system that uses null as value signal like in the case of RxJava and other java libraries. On a different topic there are some efforts to make Option leaner https://github.com/arrow-kt/arrow/pull/2780

[simon.vergauwen]

It's indeed a bit long, we opted for the length name because that felt most clear from a "std" point of view.

Also, since toNonEmptyListOrNull().toOption() causes 0 overhead we saw this as a good solution.

I think toNonEmptyListOrNone can fit into Arrow though, we're also considering keeping orNull() and orNone() I think for the other APIs in 2.0.

[mitch]

do you mind if we take a step back there? this will actually be a lot of challenge for those using arrow with spring boot, webflux, and jackson.. and if we put null within a Mono it will literally create an empty mono which will hang in production, indefinitely until killed. Jackson, also, to my knowledge can’t deserialize value classes https://github.com/FasterXML/jackson-module-kotlin/issues/199 so this will break.. everything.

[simon.vergauwen]

The PR @raulraja shared is still a POC/WIP, if we find that it doesn't cover the use-cases it should or doesn't offer any performance benefits over than Option will remain with it's current encoding.

[mitch]

thank you! I’ll watch that PR. Hopefully we take the server ecosystem into consideration for this because arrow’s Option is godsend for spring / rx

[simon.vergauwen]

We will 100% take the server eco-system in consideration ☺️ It's a vital part of the Kotlin eco-system, and Arrow will not compromise on such things.

[thanh]

fyi, I aslo use spring, webflux in production. Usually I use Either as container type instead of Option or nullable, which works well with Mono.

[Youssef Shoaib [MOD]]

I'm the author of that PR btw, I haven't really done much work on it recently since I've been busy with college, but basically it doesn't actually encode the underlying value as a null at all, even if you put a null inside of it (it uses a special underlying data class). This was a very conscious decision since (without going into too much detail) the compiler optimizes an Option<T>? Only if Option's underlying type is non-nullable. Additionally, if you use it with a Mono, I believe it will just simply be boxed, so no worries there either. On Jackson not serialising value classes, that is a very real issue, but it is one that hopefully should be fixed soon enough.