Michael Lamparski

It seems apparent to me that a properly sound way to do this will require massive restructuring of the API and careful consideration of every facet: --- If we want...

Use case or motivating example? Aside from `let &x = Box::new(3);` I'm having a hard time picturing when it would even be possible to use this; Most deref coercions I...

> This would make pattern matching be able to run arbitrary code, which wasn’t the case before. I'm not certain I see the difference from what's possible today. ([Playground](https://play.rust-lang.org/?gist=dcb36a9ba39323bad908a9c9e21a42f4&version=stable)) ```rust...

Apologies for the noise; after much faffing about I finally see what the difference is. My mental model of when deref coercions are applied was a bit "off." Apparently they...

Eh. One should then ask, "why bitwise ops but not `+` and `*`?" And I *really* don't want to see `*` implemented on arrays, as arrays are a common choice...

There should also be `try_map`. (yes, this can be implemented for arrays, unlike for iterators, because the array operation is strict)

@bbatha the current design very deliberately does not support this, and implicitly evaluates its argument to a temporary binding. The argument is that `something.compute_foo()?.another_method().do_while!(true)` can be very confusing to mentally...

Please do not replace Here with `!` because I plan to turn it into a unit struct. (for reified indices)

Hmmmm. Yes I can see why this would raise conflicting impls. The thing that makes `pluck` possible is that, if an HList contains only one copy of `T`, then there...

I definitely agree with taking the most general `Fn`-family bound where possible. (i.e. `FnOnce` on coproducts, `FnMut` on HLists). --- For `FuncMut`, the picture is less clear. You can see...