Has there been any talk of providing a `early {}` DSL with a `Raise<Unit>` , so you can use `e...

# arrow

[CLOVIS]

Has there been any talk of providing a early {} DSL with a Raise<Unit> , so you can use ensure etc for early-returns without any error message?

[Youssef Shoaib [MOD]]

That seems interesting. Do you propose providing overloads for ensure etc that expect a Raise<Unit> and hence don't require an ugly empty block?

[CLOVIS]

Yes. It would essentially be the same as nullable , but for "purely impure functions" (those that do only side effects)

[Youssef Shoaib [MOD]]

Sounds worth a PR! Only annoying thing is we'll likely need to introduce a new Raise variant specifically for Raise Unit so that we can support member extension functions without using context receivers

[Youssef Shoaib [MOD]]

I think that's what nullable does for the same reasons, but maybe I'm misremembering

[CLOVIS]

Here's an example of such function:

fun MutableSet<AccessRight>.addRightsForUser(user: User) = early {
    ensure(…)
    ensure(…)

    add(AccessRight(…, user))
}

I don't know if it's useful enough to warrant its own builder, but it's kinda ugly to have to go back to if (!condition) … in these cases

Name candidates:
• early (it uses Raise as an early return)
• do (it's just a block of code, and run is already taken)
• unit (it returns Unit)

[CLOVIS]

I think that's what nullable does for the same reasons,

I remember the same

[CLOVIS]

Maybe it could be another DSL that uses NullableRaise under the hood? Raise<Nothing?> and Raise<Unit> are isomorphic, they're both raising a singleton, so all utilities are probably the same

[CLOVIS]

By "utilities", I mean lambda-less ensure , the ignoreErrors helper, etc

[Youssef Shoaib [MOD]]

Another candidate: breakable

[CLOVIS]

I like the idea, but I would expect it to work with the break keyword. Maybe raisable ? But that might be confused as "the primary way to use Raise , since it shares the name", whereas it's really a narrow use-case

[CLOVIS]

Maybe impure {} ?

[Youssef Shoaib [MOD]]

I don't think implementing it in terms of NullableRaise would change much. The only reason we need it is so that we can define those utils without needing context receivers, but other than that NullableRaise doesn't have any custom behaviour

[Youssef Shoaib [MOD]]

impure {} is interesting because this builder will be returning Unit anyways, so this makes it clear that we're only performing side effects that can also fail and end the computation early

[CLOVIS]

For the implementation, it's probably just

inline fun unit(block: NullableRaise.() -> Unit): Unit =
    fold({ block(this) }, recover = { Unit }, transform = { Unit })

[Youssef Shoaib [MOD]]

Well, if we just make a UnitRaise, the implementation is then:

inline fun unit(block: UnitRaise.() -> Unit) = merge(block)

[CLOVIS]

> other than that NullableRaise doesn't have any custom behaviour
It already has lambda-less ensure, ignoreErrors etc, and these would be useful for the same reasons

[Youssef Shoaib [MOD]]

Yes, I meant it doesn't have any logic inside, only those utils, so using NullableRaise as an implementation detail won't give us anything really

[CLOVIS]

Well, if you create a UnitRaise , you have to duplicate them, right?

[Youssef Shoaib [MOD]]

Yeah, I was assuming that we want to 1) be able to raise(Unit) and 2) not give any special behaviour to nulls

[Youssef Shoaib [MOD]]

But if not, then we can indeed just use a NullableRaise

[Youssef Shoaib [MOD]]

Note that OptionRaise exists as well, even though it could be implemented in terms of NullableRaise, but that's because we want the available utils to be slightly different

[CLOVIS]

Yeah, raise(null) is weird here.

[CLOVIS]

I'll think about it some more 🙂 If you think it's worth creating an issue, please ping me in it (@clovis-ai on GitHub)

[Youssef Shoaib [MOD]]

I think part of this might be due to bindAll extensions, which differ between NullableRaise and OptionRaise in their types. I think in a context receivers world we'd just have nullable, impure, and option all giving us a context(Raise<Null>, Raise<None>, Raise<Unit>) and we'd have the same utilities thus for each one, with the only difference being the ultimate return type at the end.

I'll make a PR for impure, and we can continue the discussion there

[CLOVIS]

Yeah, I expect all XXXRaise classes to disappear with context receivers. Ah, I'm so hyped 😅

[Youssef Shoaib [MOD]]

https://github.com/arrow-kt/arrow/pull/3305
I've tagged you on Github as well :)