How can a BIP21 implementation support composable `Extras` params defined in multiple places? about bip21 HOT 2 OPEN

FYI I dug a bit into the API and I realized I don't like the duplication around is_known and the other methods since it can cause bugs. I think I will want to change it to something like:

struct ParamSlot<'a, 'b>(&'a mut Option<Param<'b>>);

impl<'a, 'b> ParamSlot<'a, 'b> {
    pub fn param_known(self) -> Param<'b> { self.0.take() }
}

trait DeserializationState<'de>: Default {
    fn deserialize_borrowed<'a>(&mut self, key: &str, value: ParamSlot<'a, 'de>) -> Result<ParamKind<'a, 'de>, (<Self::Value as DeserializationError>::Error, ParamSlot<'a, 'de>)> {
    self.deserialize_temp(key, value)
}

    fn deserialize_temp<'a, 'b>(&mut self, key: &str, value: ParamSlot<'a, 'b>) -> Result<ParamKind<'a, 'b>, (<Self::Value as DeserializationError>::Error, ParamSlot<'a, 'b>)>;
}

Also DeserializationError seems to exist because of lack of GAT, so I'd love to bump MSRV eventually.

from bip21.

Damn, I saw this issue before but I couldn't react for some reason and then forgot. :(

I was hoping that writing "It's inspired by serde" would make it obvious. We do it exactly like serde does, with macros. We can do either declarative or procedural. I personally prefer declarative but I know many people will want procedural, so I'll be happy to see anyone contributing that.

Here's a relevant part I wrote in the silent payment issue:

The way you compose it is you define struct MyParams { payjoin: Option<PjParams>, lightning: Option<LnParams> } (possibly Option<Result<_, _>> instead) and make DeserializationState contain states of both, you then try to feed the parameters into each and call finalize of each at the end. Allowing this is also the reason for the is_param_known method.

from bip21.