Add SupplyResponse::new

[ghost]

Pretty much self explanatory, without this, consumers of cosmwasm-std can't construct new SupplyResponse structs

[webmaster128]

Hmm, this is a problem. We have this in a different place as well. The moment this constructor is added, we cannot add fields to the response type anymore. And this is the reason there is #[non_exhaustive] on SupplyResponse.

Where do you need contructing a SupplyResponse? Is this for test code?

[ghost]

Yes exactly, just for testing. You can take a look at these PRs if you're interested

• add token supply query cw-multi-test#17
• https://github.com/public-awesome/swap/pull/9

[larry0x]

The moment this constructor is added, we cannot add fields to the response type anymore.

If backward compatibility is the concern, how about this solution. Suppose I have this struct:

#[non_exhaustive]
struct MyStruct {
    a: String,
    b: String,
    c: String,
}

impl MyStruct {
    pub fn new(a: String, b: String, c: String) -> Self {
        Self { a, b, c }
    }
}

Let's say in cosmwasm v1.2 we want to add a new field d to this. We can then do this:

#[non_exhaustive]
struct MyStruct {
    a: String,
    b: String,
    c: String,
    #[cfg(feature = "cosmwasm_1_2")]
    d: String,
}

impl MyStruct {
    #[cfg(not(feature = "cosmwasm_1_2"))]
    pub fn new(a: String, b: String, c: String) -> Self {
        Self { a, b, c }
    }

    #[cfg(feature = "cosmwasm_1_2")]
    pub fn new(a: String, b: String, c: String, d: String) -> Self {
        Self { a, b, c, d }
    }
}

This way, anyone who doesn't enable the cosmwasm_1_2 feature will get the old function signature (without d), while everyone who does enables the feature gets the new function signature (with d).

[webmaster128]

Unfortunately this conflicts with the idea that Rust features must be additive. In the given example, a MyStruct::new(one, two, three) call fails to compile once the feature is added.

We have such problems in the codebase around the ibc3 feature but they will be removed as soon as we get the chance.

[webmaster128]

What if instead we implement Default for those types. Then host code (multi-test, cw-sdk) can construct the types like this:

fn construct_me(testing_amount: Coin) -> SupplyResponse {
    let mut res = SupplyResponse::default();
    res.amount = testing_amount;
    res
}

[larry0x]

What if instead we implement Default for those types. Then host code (multi-test, cw-sdk) can construct the types like this:

fn construct_me(testing_amount: Coin) -> SupplyResponse {
    let mut res = SupplyResponse::default();
    res.amount = testing_amount;
    res
}

Sounds like a good solution

[webmaster128]

Could you check out the work in #1560 for an implementation of that approach?