Jeff Burdges

I'd epxect `is` to be a pretty common variable name, so maybe worth exploring less common words, like `Some(y) binds x && y > 5` or `x matches Some(y) &&...

As noted in zulip, you want this declared explicitly both in the trait bounds, as well as when instantiating the closure, so maybe.. ``` fn foo(f: impl PartialEq+Fn() -> T)...

I never claimed existing procmacros should be used for this feature. I suggested that "procmacro closures" would make rustc expose information about the captured variables, which then makes better ergonomics...

It shows the splitting better if you use mutable borrows like https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=95984003646c3144ac94f5ca3d201a35 If we `#[derive(PartialEq)]` for `Split` then `c1` and `c2` cannot access `Split: PartialEq`, since they cannot access `Split`....

I doubt explicit captures serve much purpose, likely `#![feature(fn_traits)]` superceeds them in practice. > I think it would be possible to write a proc macro to find the captured identifiers...

Yes, rustc would run the proc macro after rustc generates the closure. It'd only add code though, so I doubt this requires rustc "backtrack", merely that earlier passes run over...

I'd think "automatic dependencies" would address the usual issue here better: ``` [dependencies] unwanted_dependency = { ..., optional=auto } ``` This says I'll impl whatever traits unwanted_dependency creates, but only...

It's maybe helpful if people cc https://github.com/rust-lang/rust/issues/29635 whenever they'd consider using `#[fundamental]`, but do not do so for stability. This might help someone in future figure out in what form...

I think "local impls" should be done by delegation, but.. There is a large design space for delegation, so someone should explore this space. In particular you've this flavor: All...

`Fn`, `FnMut`, or `FnOnce` are closures, not functions. Ain't clear how you'd name the type of a closure, but in theory there is a type there which could satisfy extra...