Update subxt version

[pmikolajczyk41]

We bump subxt to 0.28.0 version. Main changes are due to new scale_en/decode crates used by subxt (check paritytech/subxt#842).

[SkymanOne]

Why do you need this if trait bounds are empty?

[pmikolajczyk41]

because automatically compiler will require bounds for E (in general, for every generic parameter)

[ascjones]

Perhaps to avoid having this attribute everywhere we could have a blanket impl of DecodeAsType for the Environment trait?

[pmikolajczyk41]

we could, but then I would have to provide something reasonable here:

impl DecodeAsType for E {
    fn decode_as_type(input: &mut &[u8], type_id: u32, types: &PortableRegistry) -> Result<Self, Error> {
        todo!()
    }
}

impl EncodeAsType for E {
    fn encode_as_type_to(&self, type_id: u32, types: &PortableRegistry, out: &mut Vec<u8>) -> Result<(), scale_encode::Error> {
        todo!()
    }
}

@jsdw what makes sense here?

[jsdw]

Assuming Environment is a type that can't be constructed (eg enum Environment {}) I think some like that would be fine (though I'd panic!("Shouldn't call x on Environment") on the DecodeAsType and maybe unreachable!() on the EncodeAsType one even so).

If it's at all possible to construct an Environment then personally I'd go for the trait bounds everywhere.

(Side note: I'm noting that Encode and Decode don't require such trait bounds; I wonder how that is possible because maybe we can be smarter with EncodeAsType and DecodeAsType in this regard also)

[pmikolajczyk41]

hmm... it's a trait and it feels kinda weird to have these panics in the blanket implementation :| I don't have strong opinion; @ascjones (?)

[ascjones]

Not a good idea. Just leave as is with the #[decode_as_type(trait_bounds = "")] for now

[ascjones]

Perhaps to avoid having this attribute everywhere we could have a blanket impl of DecodeAsType for the Environment trait?

[jsdw]

You could also use Payload::new() to use the documented interface (though downside is it would allocate since it doesn't specialise on static strings)

[pmikolajczyk41]

changed to new

[jsdw]

Weight is a super simple struct, so for a little added robustness/simplicity I wonder whether it's worth just writing your own version that impls EncodeAsType et al

[pmikolajczyk41]

I agree, but sp_weight::Weight comes with pretty broad API and I don't know whether it would be convenient in the end to copy just the struct (copying the whole API seems to be an overkill); I'm leaving the decision to one of this repo maintainers @ascjones ?

[ascjones]

I'm fine with a local copy of the type with a minimal API, it is likely to be highly stable.

[pmikolajczyk41]

done

[ascjones]

LGTM!

[jsdw]

Nice!