Skip to content

Trivial improvements for TapTree type#927

Merged
apoelstra merged 5 commits intorust-bitcoin:masterfrom
BP-WG:taproot/rc2-fixes
Apr 20, 2022
Merged

Trivial improvements for TapTree type#927
apoelstra merged 5 commits intorust-bitcoin:masterfrom
BP-WG:taproot/rc2-fixes

Conversation

@dr-orlovsky
Copy link
Copy Markdown
Collaborator

These are trivial fixes from extracted from now closed #922

@dr-orlovsky dr-orlovsky added minor API Change This PR should get a minor version bump RC fix labels Mar 31, 2022
@dr-orlovsky dr-orlovsky added this to the 0.28.0 milestone Mar 31, 2022
@dr-orlovsky dr-orlovsky changed the title Small taproot fixes Trivial improvements for TapTree type Mar 31, 2022
@dr-orlovsky dr-orlovsky added the trivial Obvious, easy and quick to review (few lines or doc-only...) label Mar 31, 2022
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also didn't like the name into_inner. Let's rename them both.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Copy Markdown
Member

@tcharding tcharding Apr 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One major comment.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned elsewhere, this should implement ExactLenIterator instead

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, since the iterator is core::slice::Iter, which indeed is ExactSizeIterator.
This method is just convenience.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this happens in #924: b5470bf

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 Apr 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leaf_count may be clearer name?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AsRef is needed for generic function arguments

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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].

  • TapTree is a tree, that should be viewed as a tree.
  • TaprootBuilder is 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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like leaking the internal representation at all. Is there a strong reason to do it?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, otherwise we can't use TapTree in places where TaprootBuilder is required as an argument: fn some_stuff(tree: impl AsRef<TaprootBuilder>)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the above comment, I would rather users use conversion functions.

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 Apr 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that as opposed to previous conversion, this one is OK.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

leaf_count may be clearer name?

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had an incomplete review in another tab

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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].

  • TapTree is a tree, that should be viewed as a tree.
  • TaprootBuilder is 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

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 Apr 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@sanket1729 sanket1729 modified the milestones: 0.28.0, 0.29.0 Apr 5, 2022
@sanket1729
Copy link
Copy Markdown
Member

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.

@sanket1729
Copy link
Copy Markdown
Member

@dr-orlovsky, do you have an objection to the 0.29 tag for this?

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

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.

@dr-orlovsky dr-orlovsky mentioned this pull request Apr 5, 2022
sanket1729
sanket1729 previously approved these changes Apr 5, 2022
Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK bcd9555ab096c3345c02d8d506abdbb11a867277.

@tcharding
Copy link
Copy Markdown
Member

FWIW, looks good to me.

Copy link
Copy Markdown
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one detail, strong ACK renaming.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

Force-pushed to remove as_builder and replace it with to_builder, as @Kixunil has requested.

Kixunil
Kixunil previously approved these changes Apr 6, 2022
Copy link
Copy Markdown
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 798c08ece96308489174df8b5af69c2d055adc0b

@Kixunil Kixunil added the one ack PRs that have one ACK, so one more can progress them label Apr 6, 2022
tcharding
tcharding previously approved these changes Apr 19, 2022
Copy link
Copy Markdown
Member

@tcharding tcharding left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK (excluding into_ vs to_, I admit total defeat in trying to fully understand the naming conventions for as/into/to).

@tcharding
Copy link
Copy Markdown
Member

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 into_builder and to_builder :)

@tcharding
Copy link
Copy Markdown
Member

tcharding commented Apr 20, 2022

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 :)

@dr-orlovsky dr-orlovsky dismissed stale reviews from tcharding and Kixunil via 4cdff06 April 20, 2022 08:31
@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

There was a conflict with the master; I have rebased. @sanket1729 @tcharding pls re-ACK

Copy link
Copy Markdown
Collaborator

@Kixunil Kixunil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 4cdff06

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 4cdff06

Copy link
Copy Markdown
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 4cdff06

@apoelstra apoelstra merged commit 6b57a02 into rust-bitcoin:master Apr 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

minor API Change This PR should get a minor version bump one ack PRs that have one ACK, so one more can progress them trivial Obvious, easy and quick to review (few lines or doc-only...)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants