bitcoindevkit / bdk / 10393108592

79%

push

github

Merge bitcoindevkit/bdk#1537: Use explicit names for wallet builder methods that validate rather than set

2391b765e refactor(wallet)!: rename LoadParams methods (thunderbiscuit)

Pull request description:

  This PR is a follow up to the dev call discussion where we decided it was better to PR these changes separate from #1533. This is a breaking change, but I think it's worth it because those will potentially cause runtime errors for users that expect one thing to happen and realize it's something else.

  Left out of this PR but as surfaced in the call probably worth discussing is whether these methods make sense at all or whether they should be removed entirely. What does it mean to return an error when someone loads a wallet from persistence for which the genesis hash doesn't match the one persisted? Maybe worth a new issue; this PR simply attempts to name them correctly.

  ### Description
  See [Q1 in comment here](https://github.com/bitcoindevkit/bdk/pull/1533#issuecomment-2267641603) for more context into the initial question.

  Two of the methods on the builder that loads a wallet were checkers/validators rather than setters:
  - `network()`
  - `genesis_hash()`

  This is confusing for users because when loading a wallet from persistence those things are persisted and cannot be changed, and yet seemingly the option to do that is there with those methods (so now you're re-thinking what you think you know about the changeset and persistence). Moreover, the fields on the [`LoadParams` type](https://docs.rs/bdk_wallet/1.0.0-beta.1/src/bdk_wallet/wallet/params.rs.html#116-124) are correctly named `check_network` and `check_genesis_hash`. This PR simply brings those two methods in line with what they actually do and set on the struct they modify.

  This modification was not done on the `descriptors()` method, because that one is both a validator and a setter if the descriptors passed contain private keys.

  Note ... (continued)

2 of 2 new or added lines in 1 file covered. (100.0%)

11155 of 13603 relevant lines covered (82.0%)

13131.37 hits per line