overloaded-box
and placement-in
by pnkfelix · Pull Request #809 · rust-lang/rfcs (original) (raw)
I just wanted to jot a few cases where the current desugaring still fails to do as well as I would like, even after augmenting rustc
with rust-lang/rust#22012 :
let b8: Box<[i32]> = box_!( [] );
println!("b8: {:?}", b8);
trait Invoke<A=(),R=()> { fn invoke(self: Box<Self>, arg: A) -> R; }
impl<A,R,F> Invoke<A,R> for F where F : FnOnce(A) -> R
{
fn invoke(self: Box<F>, arg: A) -> R { let f = *self; f(arg) }
}
fn with_arg<A,R,F>(f: F) -> Box<Invoke<A,R>+Send> where
F: FnOnce(A) -> R, F: Send { box_!(f) }
let b9 = with_arg(|x| x+1);
println!("b9.invoke(8): {}", b9.invoke(8));
(Both of the above cases compile fine if you use box <expr>
instead of box_!(<expr>)
. And they are both used in contexts that expect a Box<T>
from the expression (for some T
), though admittedly it is an unsized T
in both cases.)
It would be good to resolve that, or at least incorporate it into the drawbacks section if I cannot fix it quickly.
Some of the errors I'm seeing from the desugaring on the above cases is arising because the traits as written are not as general as they could be, with respect to the ?Sized
generalization marker. But I think even after those problems are addressed, there is still likely to be an issue here.
It may be possible to generalize the trick I used in rust-lang/rust#22006, instead of making it a special case just for the as
operator. But I do not know, it seems like a weird thing to try to e.g. build into the way we unify in general.