This is a non-working attempt to get #838 working.
It starts out fine, but when I try to take the final steps (adding
() as the type of "no sink wanted", and removing the old code) it all collapses under the weight of its own type inference.
Update: Never mind; I got it working-ish. I'll add a further update once it's in a better state.
Okay, it compiles. There are aspects I like and aspects I don't like.
I like these things:
Doing less in the macro is pretty excellent.
Getting rid of
ConstTypeIdis also a win.
It's a bit nice to have a simpler syntax to use when invoking the macro. (Though IMO there is enough complexity in the required implementation-function types that remembering the syntax for the macro is not much more to ask.)
I don't like these things:
I don't like the bit where we have to declare no-update implementations as having a fourth
()argument. We could solve this by reintroducing a little syntax to the macro invocation, or by figuring out if there isn't some alternative to the
as fn(_,_,_,_) -> _that we're doing now
I don't like the bit where we have to declare update implementations as taking an
UpdateSink<U>when formerly we could tell the user to use
impl Sink + Unpin. Yes, I know that
Box<dyn Sink>isn't that much slower than
impl Sink, but I kind of dislike this amount of coupling. (I wonder if we could solve this with a macro-generated shim? Probably not. I know we can't tell it the actual unboxed type that we want to pass it, since we can't name the type of a closure.)
I don't like the code duplication in our two different
IMO, we should back-burner this change at least until we know for certain what we're doing with #837: I think some of the possibilities there would moot this work, and I think I'm not currently sold on it.