Get rid of Chain as the building block for other combinators and remo… #2117
Conversation
|
Oh, and this also fixes #2118 :) |
…ve some unsafe code
|
The test |
| fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> { | ||
| Poll::Ready(loop { | ||
| match self.as_mut().project() { | ||
| __InternalFlattenProjection::First(f) => { |
There was a problem hiding this comment.
This is an internal type of the generated code which shouldn't be used. You can use the #[project] attribute to allow matching on the projected variants (see https://docs.rs/pin-project/0.4.8/pin_project/attr.pin_project.html#enums)
There was a problem hiding this comment.
Yeah, I've fixed that in the larger PR I have :)
That is failing because of changes to the generator transform in |
|
Superceded by #2128 |
…ve some unsafe code
This is just the first step in a potential refactor that could remove a lot of safe and unsafe code, and I wanted to test the waters before going all out. As you can see the amount of code that can be deleted this way is high!
The basic ideas are:
pin-utilstopin-projectas it has a safe API and supports enums, which results in smaller combinator sizes in memory.Chainas it is unnecessarily complicated. We can instead build up from primitive combinators likeFlattenandMap.There are a couple of open questions:
Is it OK to use raw type aliases as I have done with
Then? Strictly speaking, it's a breaking change, however, it's exceptionally unlikely that it will actually cause any problems. If we don't want to do this, the fallback would be to have a macro to define a load of newtype wrappers that automatically implement the relevant traits.Is it OK to get rid of the unused type parameter on
Then? This is a breaking change, although you wouldn't typically name this parameter during normal usage. If we don't want to get rid of it, then we'll need a newtype wrapper for at leastThenand any other combinators with unused generic parameters.