Consider merging this crate and pin-utils about pin-project HOT 11 CLOSED

Small update to my comment above, I've now published ergo-pin. My primary reason for writing that was while experimenting with pinning collections and pinned iterators (to allow using generators to create an iterator), so that was a usecase where I could have been using pin-project (although wasn't) and be completely outside the futures ecosystem.

from pin-project.

I think it would be useful for there to be a single crate which handles all of these pinning operations. Currently, users that want both safe pin projections and stack pinning need to use two separate crates.

I agree with you. I submitted rust-lang/futures-rs#1686 for this, but, we can consider redefining in pin-project.

from pin-project.

I've become relatively indifferent about adding pin_mut to this crate. However, I think it would be a good idea to reach a decision one way or the other, as this is the only remaining open issue 😄

from pin-project.

cc @Nemo157 Any thoughts on this?

from pin-project.

I actually find pin_mut! quite annoying to use in practice because of the extra binding needed (I fall into the “less having to think of names is better” camp, so commonly the thing that needs pinning is something that I wouldn’t normally bind to a variable). When I last wrote some code that involved a lot of pinning I threw together this crate as an experiment in better ergonomics, but I didn’t get around to actually publishing it.

But, I do agree that it would be good to have a single crate exporting all utilities that you need when working with Pin.

from pin-project.

I actually find pin_mut! quite annoying to use in practice because of the extra binding needed (I fall into the “less having to think of names is better” camp, so commonly the thing that needs pinning is something that I wouldn’t normally bind to a variable).

Yeah, I also feel pin_mut! is not ergonomic (nevertheless, I added it to futures 😁.).

When I last wrote some code that involved a lot of pinning I threw together this crate as an experiment in better ergonomics, but I didn’t get around to actually publishing it.

As long as you look at the code in the tests directory, it looks like it's easy to use...

from pin-project.

The ergonomic API for stack pinning has not been established yet, so if adding these support to pin-project at this time, I think it needs to add unergonomic pin_mut to keep stability.

And if we want to experiment with ergonomic things, I think it should be done in another library.

from pin-project.

Can we not add pin_mut at a later time or what ever the "ergo" api will be. Don't think I've needed pin_mut where I have pin-project and not futures-util?

from pin-project.

Actually, futures_util::pin_mut/futures::pin_mut are sufficient for my use-case and I'm also interested in trying ergo-pin, but I don't have a strong opinion about whether to do this on pin-project itself.

from pin-project.

I'm still torn about this. Here are some updates and my opinions (TL;DR: I feel there are one advantage and some relatively minor drawbacks):

• I'm now a maintainer of pin-utils.
• pin-utils will only provide stack-pinning util in the future (rust-lang/pin-utils#29)
• There are two pin-project crates, and the decision here is also propagated to lite.
• Adding a futures-util dependency for use only a stack pinning utility is not good. (However, as pin-project and dependencies require relatively long compile times, "add pin-project dependency for use only a stack pinning utility" may not happen very often.)
• I think after removed the project attributes (#225) should allow the API to be considered stable enough (i.e., v1.0). Not so when adding stack pinning API.
• pin-utils is a really small crate that won't impact compile time with or without merging. (Depending on the situation, but using pin-project's stack pinning utility instead of pin-utils should increase overall compile time because pin-project is only compiled after proc-macro is compiled. But I feel some users are more sensitive to the increasing number of dependencies than the actual compile time.)
• It's convenient to have all pin related utilities in one place.
• If we don't add this, the name of pin-project is descriptive about what this crate does.

from pin-project.

I'm going closing this because the benefits of doing this don't seem to outweigh the drawbacks I said in the comment above, at this time.

If anyone can explain more about the benefits of doing this, we can reopen it.

from pin-project.