Removed bounds on Append, PluckTail, Prepend, and Pluck. #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While I completely agree with the stated goal of making
<() as Append<T>>::Output = (T,)
, I feel PR #6 introduced overly restrictive and unnecessary bounds.This has come up for me because I found it necessary to implement my own Empty types, and I still want to be able to append them and output a tuple. But the bound on
Append::Output
makes it impossible to implement that, because I cannot implementPluckTail
a second time on(T,)
.I am unsure why these bounds were necessary for the stated goal.
().append(x).pluck_tail()
is completely backwards compatible without them with the other changes in PR #6. I understand that with a custom empty type it wouldn't be (the sequence would return()
instead of the original custom empty), but I find that less of a limitation than not allowing a custom implementation at all, so I feel removing them makes the library more useful.