Feature request `nullableLossy` to convert any function decl

Question

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 · Answer

That name cannot be hard to find

simon.vergauwen · Answer

So an alias for `recover blabla null ` right

simon.vergauwen · Answer

There has been a discussion before about `getOrNull ` but that looks weird smile

simon.vergauwen · Answer

`effect getOrNull ` also works

CLOVIS · Answer

gt So an alias for `recover blabla null ` right Yes that s an easier way to write it than `either getOrNull `

Javier · Answer

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 · Answer

I m definitely open for such a feature but it s very hard to name sweat smile

Javier · Answer

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

CLOVIS · Answer

gt 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 · Answer

Just brainstorming `fromEffectOrNull ` `fromRaiseOrNull `

Javier · Answer

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 · Answer

`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 · Answer

gt 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 · Answer

yeah I don t like `from` too just throwing ideas

simon.vergauwen · Answer

`recoverNull `

simon.vergauwen · Answer

As an alias for the `recover null ` pattern thinking face

simon.vergauwen · Answer

`recoverOrNull` seems incorrect smile

Javier · Answer

`recoverOrNull`

simon.vergauwen · Answer

That doesn t seems correct then I guess it should be `recoverWithNull `

simon.vergauwen · Answer

confused

CLOVIS · Answer

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 · Answer

`recoverWithNull` sounds fine

CLOVIS · Answer

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

Javier · Answer

Wouldn t `recover orNull ` correct

simon.vergauwen · Answer

Not a big fan of `Lossy` tbh sweat smile and creating more sublanguage

simon.vergauwen · Answer

`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 · Answer

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 · Answer

< 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 · Answer

there is `nullable ` in Arrow upside down face

Javier · Answer

I know I mean in Kotlin stdlib

CLOVIS · Answer

^ that s why I wanted to reuse the name slightly smiling face

Javier · Answer

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

CLOVIS · Answer

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 · Answer

I am not a fan of using ` ` I use named params in those use cases

simon.vergauwen · Answer

No one is a fan of ` ` joy it s a necessary evil sadly somtimes

CLOVIS · Answer

```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 · Answer

Not sure if that is more readable either thinking face

CLOVIS · Answer

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 · Answer

I d recommend `either getOrNull ` tbh it s probably going to be most readable

CLOVIS · Answer

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 · Answer

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

CLOVIS · Answer

gt 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 · Answer

Those would conflict anyway

Stylianos Gakis · Answer

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 · Answer

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 · Answer

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 · Answer

I m writing a few more details in the PR itself

CLOVIS · Answer

Oh nice so it s used like this ```fun fooOrNull = nullable ignoreErrors foo ```

Alejandro Serrano.Mena · Answer

yep

CLOVIS · Answer

Then I d like to change my issue from proposing a new construct to mentioning ignoreErrors in nullable s documentation blush

CLOVIS · Answer

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

Alejandro Serrano.Mena · Answer

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