Add ensure

[ethanfrey]

Closes #468

[ueco-jb]

Personally I'm not a fan, for me this syntax is a bit unintuitive.
It should "sound" like: ensure that {condition}, otherwise {error}, but because there's no "separation" between condition and returned error I need to spend this extra half a second to reverse condition and basically decode macro in head. :)
Long story short, looking at original syntax if {condition} then {error} I read code faster then with proposed macro.

But leaving approve anyway. Code is clean, in some places shorter.

[ueco-jb]

Is this a good place for this macro? If we'd commit to using it, basically every contract could use it so some packages/utils seems more appropriate imo.

[ethanfrey]

I think it belongs in cosmwasm_std. But once it is there it is hard to change.

Putting it here temporarily so we can experiment with it.

[ethanfrey]

That said, renaming cw0 to utils makes sense to me

[maurolacy]

I like it. Maybe better called ensure_or, but no need to change it.

[ueco-jb]

I actually like Mauro's idea very much, it basically solves my issue and IMO sounds more Rusty.

[ethanfrey]

We could make ensure_or and fail_if which do the opposite actions.

I took ensure! naming from the failure crate.

[webmaster128]

Maybe better called ensure_or, but no need to change it.

Why? ensure!(condition, error) is pretty much how every assertion in every language works. I don't see how it would help.

[webmaster128]

Now what if we add

Suggested change

	return Err($e);
	return Err($e.into());

Wouldn't that open up a huge space of use cases in a very natural way?

[ethanfrey]

I thought this... but then it requires you to explicitly define the output. Like in the closures in the tests.

Maybe not being able to infer the type is worth it for the flexibility. 🤷

Can you make a PR on top. I am especially interested in the ergonomics of the change in real contract usages, not just my silly test code. It may be able to infer all types in the contracts, so my hesitation is unwarranted.

[webmaster128]

Will do. This would make this macro behave like try! and ? when it comes to conversion where you have the same restriction on inference. See

#[macro_export]
#[stable(feature = "rust1", since = "1.0.0")]
#[rustc_deprecated(since = "1.39.0", reason = "use the `?` operator instead")]
#[doc(alias = "?")]
macro_rules! r#try {
    ($expr:expr $(,)?) => {
        match $expr {
            $crate::result::Result::Ok(val) => val,
            $crate::result::Result::Err(err) => {
                return $crate::result::Result::Err($crate::convert::From::from(err));
            }
        }
    };
}

[maurolacy]

Maybe better called ensure_or, but no need to change it.

Why? ensure!(condition, error) is pretty much how every assertion in every language works. I don't see how it would help.

I agree. In fact I mentioned the same in planning today.

[ethanfrey]

Just rebased on main.

Happy to either merge this with future PRs on top to improve, or others to PR on this to improve it.
I do see room for improvement, but I do not want to own the future work.

My main goal was to get something "good enough" into cw-plus utils, that we could iterate on. Either before 0.10.0 or after.

[webmaster128]

Don't get blocked by my suggestion. We can have a second look when migrating it to cosmwasm_std

[ethanfrey]

I think the suggestion is good.
Happy to merge now.

If someone wants to try this in a new PR, go for it.