Trivial improvements for TapTree type#927
Trivial improvements for TapTree type#927apoelstra merged 5 commits intorust-bitcoin:masterfrom BP-WG:taproot/rc2-fixes
Conversation
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
In f6dcd2cc56d942c33619bb526c089d171b04f9ab:
I think as_inner' is an extremely weird name for this. Yes, as an implementation detail a TapTreeis a finalizedTaprootBuilder`, but this doesn't necessarily make conceptual sense and I don't think we want to guarantee it.
I'd be ok with the same method named as_builder, or preferably into_builder which takes ownership.
There was a problem hiding this comment.
I also didn't like the name into_inner. Let's rename them both.
There was a problem hiding this comment.
Renamed & force-pushed. Also renamed from_inner and added standard conversion implementations which makes dev life easier (I found it really unnatural to work with the current TapTree/TaprootBuilder conversions in downstream crates due to lacking APIs).
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
| /// A `TapTree` iff the `builder` builder is complete, otherwise return the inner as `Err`. | |
| /// A `TapTree` iff the `builder` is complete, otherwise return the `builder` as `Err`. |
Not part of this PR but the return section header could be pluralized i.e., # Returns.
There was a problem hiding this comment.
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
As mentioned elsewhere, this should implement ExactLenIterator instead
There was a problem hiding this comment.
It does, since the iterator is core::slice::Iter, which indeed is ExactSizeIterator.
This method is just convenience.
There was a problem hiding this comment.
I think we should add this using the len method then if really needed. Because the current implementation seems wrong to me. I think it is counting something else, not the number of leaves.
There was a problem hiding this comment.
leaf_count may be clearer name?
There was a problem hiding this comment.
It is not leaf count: in the future with hidden parts of the tree we will not know about how many leaves are hidden. So probably better to have it as known_scripts_count.
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
nit:
I would rather let users call as_builder instead rather than an indirect AsRef. Maybe it's just only me, but TapTree and TaprootBuilder are not similar conceptually in the operations they do. I would only conservatively implement AsRef when the conversion is super-obvious or should be hidden from the user.
There was a problem hiding this comment.
AsRef is needed for generic function arguments
There was a problem hiding this comment.
Indeed. It is required for generic functions, but I don't think we should be blindly following conventions. Sometimes are underlying the same things: Ex([u8; 32]) and TapLeafHash can be AsRef because both are both hashes.
TapTree and TaprootBuilder are not similar conceptually in the operations they do, unlike TapLeafHash and [0u8; 32].
TapTreeis a tree, that should be viewed as a tree.TaprootBuilderis a builder designed to construct the tree.
Same comment for Borrow. Many APIs for Builder don't make sense for TapTree, which is why I don't want indirect indirection using AsRef
There was a problem hiding this comment.
I don't like leaking the internal representation at all. Is there a strong reason to do it?
There was a problem hiding this comment.
Yes, otherwise we can't use TapTree in places where TaprootBuilder is required as an argument: fn some_stuff(tree: impl AsRef<TaprootBuilder>)
There was a problem hiding this comment.
As mentioned in the above comment, I would rather users use conversion functions.
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
nit:
Same comment as the previous commit. Is there any reason to do this? Have we done this for inner types before? I think we should avoid implementing it unless we have a reason. Ref, Deref (IMO) should only be implemented on types that are super-obvious to convert and only if they are really needed.
Allowing function args that accept these is however another story.
There was a problem hiding this comment.
There is a reason to do this and I always do that for the new types. Deref, otherwise, is not always useful for them.
Some information: https://itfanr.gitbooks.io/rust-doc-en/content/borrow-and-asref.html
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
Note that as opposed to previous conversion, this one is OK.
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
leaf_count may be clearer name?
sanket1729
left a comment
There was a problem hiding this comment.
Had an incomplete review in another tab
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
Indeed. It is required for generic functions, but I don't think we should be blindly following conventions. Sometimes are underlying the same things: Ex([u8; 32]) and TapLeafHash can be AsRef because both are both hashes.
TapTree and TaprootBuilder are not similar conceptually in the operations they do, unlike TapLeafHash and [0u8; 32].
TapTreeis a tree, that should be viewed as a tree.TaprootBuilderis a builder designed to construct the tree.
Same comment for Borrow. Many APIs for Builder don't make sense for TapTree, which is why I don't want indirect indirection using AsRef
src/util/psbt/map/output.rs
Outdated
There was a problem hiding this comment.
I think we should add this using the len method then if really needed. Because the current implementation seems wrong to me. I think it is counting something else, not the number of leaves.
|
I have moved this to 0.29 since this is not a bug fix and a slight feature improvement with some bugs. There are some discussions that might take some time to resolve. At this rate, we will never have a release until we have a perfect taproot release(which is basically impossible). It has already been months since we started the RC cycle that we might have had two major releases. |
|
@dr-orlovsky, do you have an objection to the 0.29 tag for this? |
|
Removed everything you suggested to remove, @Kixunil and @sanket1729. I will not object to postpone it. But if you have time, I think it will be cool to get the rest of the pr (which is really trivial) just not to require breaking changes after. |
sanket1729
left a comment
There was a problem hiding this comment.
utACK bcd9555ab096c3345c02d8d506abdbb11a867277.
|
FWIW, looks good to me. |
Kixunil
left a comment
There was a problem hiding this comment.
Just one detail, strong ACK renaming.
|
Force-pushed to remove |
Kixunil
left a comment
There was a problem hiding this comment.
ACK 798c08ece96308489174df8b5af69c2d055adc0b
tcharding
left a comment
There was a problem hiding this comment.
ACK (excluding into_ vs to_, I admit total defeat in trying to fully understand the naming conventions for as/into/to).
I rescind my statement of confusion, as if this minute I am in total understanding of that damnable table and ACK the naming |
|
lolz, this one has rc-fix and milestone 0.29 - lets totally get rid of the rc-fix label soon as we do this release :) |
|
There was a conflict with the master; I have rebased. @sanket1729 @tcharding pls re-ACK |
These are trivial fixes from extracted from now closed #922