Feature request: `nullableLossy` to convert any fu...

# arrow

[CLOVIS]

Feature request: nullableLossy to convert any function declared with Raise , transforming any failed values in null → https://github.com/arrow-kt/arrow/issues/3138

[Javier]

That name cannot be hard to find?

[simon.vergauwen]

So an alias for recover({ blabla() }) { null }, right?

[simon.vergauwen]

There has been a discussion before about getOrNull { } but that looks weird 😄

[simon.vergauwen]

effect { }.getOrNull() also works

[CLOVIS]

So an alias for recover({ blabla() }) { null }, right?

Yes, that's an easier way to write it than either { }.getOrNull()

[Javier]

Yeah, first I think was getOrNull { }, but it is a global function which looks generic but only works with Raise, I don't think it is a good name

[simon.vergauwen]

I'm definitely open for such a feature, but it's very hard to name 😅

[Javier]

I was thinking something related to runCatching, but I cannot get a good name... yeah, hard name

[CLOVIS]

That name cannot be hard to find?

Honestly, I have always expected nullable to behave like this. I believe many other people may as well, which is the reason I want to name it nullableXXX , so you can discover it through auto-complete

[Javier]

Just brainstorming:
• fromEffectOrNull { }
• fromRaiseOrNull { }

[Javier]

Yeah I understand you, but from my point of view, I wouldn't find that name if I don't look for it on the docs, I would look to something that start or at least includes raise in the name

[CLOVIS]

from isn't really a prefix I see often?
• effectOrNull {} : but it's called Raise now, right? Why introduce something using the old name?
• raiseOrNull {} : that really looks like something that raises, not something that capture raises

[CLOVIS]

I would look to something that start or at least includes raise in the name

I don't know, all existing builders are named after what they produce—it's not eitherFromRaise , nullableFromRaise , etc

[Javier]

yeah, I don't like from too, just throwing ideas

[simon.vergauwen]

recoverNull { } ?

[simon.vergauwen]

As an alias for the recover({ }) { null } pattern 🤔

[simon.vergauwen]

recoverOrNull seems incorrect 😄

[Javier]

recoverOrNull

[simon.vergauwen]

That doesn't seems correct, then I guess it should be recoverWithNull { }

[simon.vergauwen]

😕

[CLOVIS]

How readable would it be in a code review without IDE features? I would probably assume recoverNull means "do some recovery when the block returns `null`"

[CLOVIS]

recoverWithNull sounds fine

[CLOVIS]

I'm not sure what the case against nullableLossy is, though: it's a variant of nullable , but swallows the error

[Javier]

Wouldn't recover { }.orNull() correct?

[simon.vergauwen]

Not a big fan of Lossy tbh 😅, and creating more sublanguage

[simon.vergauwen]

recover { }.getOrNull() is what you could do with effect { }.getOrNull() but it's the same in length as what @CLOVIS is trying to solve either { }.getOrNull()

[CLOVIS]

Well, my goal is mostly readability:

fun fooOrNull() = either { // why it is building an either?
  // a lot of code
}.getOrNull() // nobody expects something to happen after the closing brackets

[Javier]

@CLOVIS As I am not an expert on FP in general, my POV is there are 0 well-known APIs in Kotlin with nullable as a prefix, so for a beginner, it will be impossible to find it.

[simon.vergauwen]

there is nullable { } in Arrow 🙃

[Javier]

I know, I mean in Kotlin stdlib

[CLOVIS]

^ that's why I wanted to reuse the name 🙂

[Javier]

Personally I liked the move of Arrow to looks like Kotlin with getOrNull APIs

[CLOVIS]

I guess this is a bit better:

fun foo() = recover({
    // a lot of code
}) { null }

but the brackets have to be inside the parens, which I'm not a fan of for large functions, it breaks the mental model of "`either` is a decorator of the rest of the function"

[Javier]

I am not a fan of using ({, I use named params in those use cases.

[simon.vergauwen]

No-one is a fan of ({ 😂 it's a necessary evil sadly somtimes

[CLOVIS]

fun foo() = recover(
    block = {
        // a lot of code
    },
    recover = { null }, 
)

is readable, but it's much more verbose, and now the code is 2-levels deep inside of 1

[simon.vergauwen]

Not sure if that is more readable either 🤔

[CLOVIS]

For someone who's not familiar with Arrow, I believe it is, because it makes more explicit what the happy path is and what the recovery path is

[simon.vergauwen]

I'd recommend either { }.getOrNull() tbh, it's probably going to be most readable

[CLOVIS]

In short functions, probably, but as soon as it's more than 5 or 6 lines, I really don't expect an either {} call to have anything at its end

[Javier]

What about nullable {}? But it would need to have the same package as the original one in order to have priority

[CLOVIS]

What about nullable {}?

I feel like it would be really confusing to have two functions with the same name, one of which swallowing errors silently

[simon.vergauwen]

Those would conflict anyway.

[Stylianos Gakis]

I’d always go with existing functions like either { }.getOrNull() or just effect {}.getOrNull() here, and if a new function was introduced in our local codebase I’d probably advocate against it. Easier to use the standard tools that everyone understands and use them together as they are meant to be used, as opposed to introducing yet another function which simply wraps 2 function calls which will be looking foreign to most arrow users.

[Davio]

I think it's a good idea to hook into a developer's muscle memory (basically the principle of least surprise), so try and find a name which the developer will likely try out first or recognize from another library.

runCatching has getOrNull
Optional has getOrNull
Casting methods have 'orNull' variants such as toIntOrNull as a way to turn the exception into a null-value

[Alejandro Serrano.Mena]

sorry for being late to the discussion, but at some point we discussed this too, and we came to the following design: use nullable but introduce ignoreErrors that does exactly that https://apidocs.arrow-kt.io/arrow-core/arrow.core.raise/-nullable-raise/ignore-errors.html

[Alejandro Serrano.Mena]

(I'm writing a few more details in the PR itself)

[CLOVIS]

Oh, nice, so it's used like this?

fun fooOrNull() = nullable {
    ignoreErrors { foo() }
}

[Alejandro Serrano.Mena]

yep

[CLOVIS]

Then I'd like to change my issue from proposing a new construct to “mentioning ignoreErrors in nullable's documentation” 😊

[CLOVIS]

I'll edit it later, and maybe I'll create a PR too if I have time

[Alejandro Serrano.Mena]

thanks, you've been wonders for us discovering all the hidden corners of Arrow we forgotten to cover in the docs 😄 ]