I personally oversee that it doesn’t happen, so it isn’t expected :smile:

# arrow

[pakoito]

I personally oversee that it doesn’t happen, so it isn’t expected 😄

[kevinherron]

ha, I was going to suggest an unsafeUnwrap() on Try next

[kevinherron]

I guess that can remain an extension function in my own code 🙂

[pakoito]

If we were to add it, it’d be on kategory-tests, which is the only place it may be used

[pakoito]

is that your case?

[kevinherron]

mostly using it in my tests as well

[kevinherron]

i think everywhere in non-test code I’m using getOrElse or fold or my onSuccess and onFailure extensions (also want to PR those)

[pakoito]

makes sense 😄

[pakoito]

right now Raul is going though the refactor, if you check the massive PRs

[pakoito]

ETA a couple of weeks

[raulraja]

@kevinherron in tests you can always compare against Success(value). I've never had the need to use Try#get or Option#get. Also no need to use onSuccess or onFailure either those are just variants of fold where in the left you return Unit and in the right you perform effects explicitly.

[raulraja]

Everything in those datatypes is pretty much implemented in terms of fold

[kevinherron]

I understand you can implement them in terms of other functions, almost always fold, but it’s for readability

[kevinherron]

onSuccess reads much clearer than a fold where you return Unit or whatever default

[kevinherron]

hoping there can be a balance between functional ideals and the pragmatism i associate with Kotlin here

[Itua]

Are you applying an action to the argument of onSuccess or you are returning the value if it’s successful when you call onSuccess? If it’s the latter, the name `onSuccess`/`onFailure` can be miss-leading. The name is similar to the callback naming idioms.

[kevinherron]

onSucccess((T) -> Unit) and onFailure((Throwable) -> Unit)

[kevinherron]

common in other libraries and well understood

[Itua]

Gotcha

[raulraja]

Those are fine as extensions if we add them under an unsafe module or package. The distinction is that kategory and whatever it becomes is to be purely functional and other needs such as unsafe operators can be explicitly imported so that users are aware that is discouraged since those are a frequent source of bugs.

[kevinherron]

I like the idea of an unsafe module

[raulraja]

@kevinherron currently adding this to a PR:

const val DeprecatedUnsafeAccess: String = "This function is unsafe and will be removed in future versions of Arrow. Replace or import `arrow.syntax.unsafe.*` if you wish to continue using it in this way"

then in Try

@Deprecated(DeprecatedUnsafeAccess, ReplaceWith("getOrElse { ifEmpty }"))
abstract fun get(): A

as I port the funktionale data types over to arrow.