Make pair extensible 2

[maurolacy]

This is a (breaking) version of Pair, which supports the natural order of fields. Closes #1100.

[uint]

I keep looking at these PRs and can't stop thinking that by the time we're doing type Pair<A, B> = (A, B), we might as well just write functions that operate on generic tuples directly.

Doesn't Pair<String, String> feel like an unnecessary complication over just (String, String)?

[maurolacy]

I keep looking at these PRs and can't stop thinking that by the time we're doing type Pair<A, B> = (A, B), we might as well just write functions that operate on generic tuples directly.

Doesn't Pair<String, String> feel like an unnecessary complication over just (String, String)?

This is a good point. Pair is good for clarity, but so is (K, V). And default arguments are not so useful anymore, now that we need to specify the first to declare the second.

I would say, create a specific issue for it, and let's see how it looks.

[webmaster128]

I keep looking at these PRs and can't stop thinking that by the time we're doing type Pair<A, B> = (A, B), we might as well just write functions that operate on generic tuples directly.

Doesn't Pair<String, String> feel like an unnecessary complication over just (String, String)?

Wise words. This is in line with my feeling that we try to do too many things with one symbol.

What if we leave Pair untouched and replace Pair2<X, Y> with (X, Y) in CosmWasm/cw-plus#432?

[maurolacy]

What if we leave Pair untouched and replace Pair2<X, Y> with (X, Y) in CosmWasm/cw-plus#432?

OK with me.

[uint]

What if we leave Pair untouched and replace Pair2<X, Y> with (X, Y) in CosmWasm/cw-plus#432?

Sounds pretty good!

[webmaster128]

The term Pair emerged from KV as clippy started to enforce CamelCase names types. Should we rename it to samething more specific, such as (data base) Record? This seems to be the term used in https://en.wikipedia.org/wiki/Key%E2%80%93value_database

[maurolacy]

Record makes more sense. I agree that the usefulness of the type comes from having one fixed and one default arg; and one specific use case.

[ethanfrey]

I strongly oppose changing the names to A and B, but rather keep K and V.

Using the natural ordering for types makes sense. Curious as to what level of contract breakage this makes (not a strong argument, but at least good to know). Can you do a brief check of the cw-plus/contracts for usages of Pair?

[ethanfrey]

I am strongly against using A and B here. This will only add to more dev confusion.

At least having some type hints would be good. I commented on the issue to the same effect.

[ethanfrey]

I see this as a cleaner approach than using <V, K> types, but also more breaking. (Switching the order of arguments to be (v, k) would be MUCH more breaking.

My question is how much does this break contract code. This will affect storage-plus, but if we update that (one hour maybe), then do we have to also update all the contracts that use range? Or is this just implicit info used by the compiler.

[maurolacy]

I think it's just an implicit / type alias thing. Did the change to (K,V) in cw-plus #432 and it was pretty straightforward.

[ethanfrey]

Sounds good

[ethanfrey]

I agree with the idea to leave Pair as it is now, and use (K, V) where both are defined.

I also searched for all usages of Pair in cw-plus contracts and only found 2. In cw721-base and cw1155-base:

fn parse_approval(item: StdResult<Pair<Expiration>>) -> StdResult<cw721::Approval> {
    item.and_then(|(k, expires)| {
        let spender = String::from_utf8(k)?;
        Ok(cw721::Approval { spender, expires })
    })
}

I assume this is very seldom used by other contract devs, or outside of storage-plus really.

Feel free to rename to Record if you wish. And let's just have a new type in storage-plus

[ethanfrey]

I guess time to close this, along with #1101?

[webmaster128]

Thank you for the great discussion and inputs from everyone!