Languages encourage the behavior they make easy, and discourage the behavior they make difficult. Rust discourages making lambda captures explicit, because you need to pollute the outer scope or define a nested scope, and even with a nested scope, you can still access variables you didn't pseudo-capture in the nested scope (meaning you can't enforce explicit captures). Additionally I do not appreciate your flippant trolling and dismissal of my arguments.
> If it would, then you already do not need it, because you can use the precise capture pattern (a block expression around a `move` closure) in order to create your clone and the clone macro is just a convenience.
gtk-rs requires shared mutability. Rust discourages shared mutability. I find that pre-cloning shared pointers for every GUI method I want to bind sufficiently painful (as opposed to lacking an unneeded convenience) I would avoid using gtk-rs if not for the clone! macro (and even with it, subclassing was confusing enough and GTK4 so buggy on X11 that I quit anyway).
> That's literally just a repetition of your previous sentence.
No, my previous sentence (was intended to) describe capturing portions of structs (usually by value or trivial copy, always without mutating the original data), whereas this one describes invoking copy constructors of refcounted pointers within the capture block (mutating data visible by the original pointer).
Languages encourage the behavior they make easy, and discourage the behavior they make difficult. Rust discourages making lambda captures explicit, because you need to pollute the outer scope or define a nested scope, and even with a nested scope, you can still access variables you didn't pseudo-capture in the nested scope (meaning you can't enforce explicit captures). Additionally I do not appreciate your flippant trolling and dismissal of my arguments.
> If it would, then you already do not need it, because you can use the precise capture pattern (a block expression around a `move` closure) in order to create your clone and the clone macro is just a convenience.
gtk-rs requires shared mutability. Rust discourages shared mutability. I find that pre-cloning shared pointers for every GUI method I want to bind sufficiently painful (as opposed to lacking an unneeded convenience) I would avoid using gtk-rs if not for the clone! macro (and even with it, subclassing was confusing enough and GTK4 so buggy on X11 that I quit anyway).
> That's literally just a repetition of your previous sentence.
No, my previous sentence (was intended to) describe capturing portions of structs (usually by value or trivial copy, always without mutating the original data), whereas this one describes invoking copy constructors of refcounted pointers within the capture block (mutating data visible by the original pointer).