Perform implicit clone into closures for variables made with hooks

[kirillsemyonkin]

The Problem

One of the main concerns about Yew developer experience is that .clone()s take up a significant part of the function component's vertical real estate:

let a = ...;
let b = ...;
let c = ...;
let d = ...;

let onclick = {
    let a = a.clone();
    let b = b.clone();
    let c = c.clone();
    let d = d.clone();
    move || ...a...b...c...d...
};
// vs
let onclick = || ...a...b...c...d...;

The main reason for this is that Rust natively does not support implicit cloning for types like Rc, which means clones should happen manually. This means such functionality should either be forced into Rust (good luck), or recreated manually with the №1 tool made for such wishes: (procedural) macros.

Macro Brainstorming

If we want to implement macro, ideally it would determine what values are ImplicitClone, and transform lambdas into move closures (hereinafter closure transforms), .clone()ing appropriate values first:

let a = ...some implicit clone value...;
let f = || ...a...;

// would become

let a = ...some implicit clone value...;
let f = {
    let a = a.clone();
    move || ...a...
};

The main roadblock in front of simply creating this feature is that procedural macros operate on tokens (simple structures of words), not on semantics (types). This means it is impossible to know which variables (variable names) are ImplicitClone without recreating the whole type analyzer inside of the procedural macro's logic. This means some variable names (tokens!) need to be marked as implicitly cloneable (hereinafter marked variables) so that we can determine if we can transform the closure creation with cloning those variables.

A crate named clown (clone + own) does this using the honk! macro inside the closure. The problem with it is that it is basically .clone() that has been moved from before closure to inside the closure, providing barely any boilerplate reduction (same goes for Rust RFC 3512).

A similar approach may be doing the marking of the variable during its creation:

let a = cloneable!(...); // now we know that `a` can participate in closure transforms
cloneable!(let a = ...); // alternative syntax
let cloneable!(a) = ...; // yet another alternative syntax

This would solve 99% of the problematic code: all the millions of clones that come after the variable declaration would be gone, leaving only one line that is still marked with anything.

Fun Fact: Copy values (except maybe references or other generic-over-lifetimes values?) would still behave as usual and do not need to be taken in consideration.

Additionally: let b = a; where a is a marked variable should also make b be marked as participating in closure transforms.

Yew's Special Sauce

We could strive for fixing 100% of the problematic code in Yew in particular. Most, if not all, of the ImplicitClone values come from use_state, sometimes from other hooks (but usually all hooks return either a (), Copy or ImplicitClone value). This means for marking variables, hooks may mark the variable names:

let a = use_...(...); // now we know that `a` can participate in closure transforms

Of course, this may not be used as-is. Main issue is that hooks aren't actually limited to be only ImplicitClone in its return values, but that can be made a breaking change: during #[hook] declaration the return type has to be ensured to be ImplicitClone:

#[hook]
fn use_...(...) -> ReturnType { ... }

// transforms into (following code is valid in Rust! I am only worried about `Copy` itself, which is not `ImplicitClone`)

fn use_...(...) -> ReturnType where ReturnType: ImplicitClone { ... }

// alternatively (if `Copy` (which is `: Clone`) is a must to be preserved):

fn use_...(...) -> ReturnType where ReturnType: Clone { ... }

[kirillsemyonkin]

Last part may be fixed in the ImplicitClone crate with specializations (currently nightly):

#![feature(specialization)]

default impl<T: Copy> ImplicitClone for T {
}

Since it is a marker trait, there are basically no implementation collisions possible, so I believe it should be a thing even without specializations. Can anyone work a proposal into the Rust language for allowing marker trait implementations to be repeatable (or find an existing proposal for me)?

[Ddystopia]

Specializations will not be stabilized any time soon (if at all). But you can do tricks like autoref specialization as a workaround

[kirillsemyonkin]

@Ddystopia impl<T: ?Sized> ImplicitClone for &T is a thing, it exists because references are Copy, it is analogous to impl<T: ?Sized> Clone for &T. It used to be only impl ImplicitClone for &'static str in one of previous versions of the crate.

[kirillsemyonkin]

Issue for ImplicitClone: yewstack/implicit-clone#32

[tguichaoua]

A workaround to this problem could be to add a clone! macro (probably with a better name to avoid name collision) to the yew's prelude.

macro_rules! clone {
    ( $($var:ident),* $(,)? ) => {
        $( let $var = $var.clone(); )*
    };
}

Usage

let a = use_state(|| 0);
let b = use_state(|| 0);
let c = use_state(|| 0);

let on_click = {
    clone!(a, b, c);
    Callback::from(move |_| {
        a.set(1);
        b.set(2);
        c.set(3);
    })
};

[kirillsemyonkin]

If not

let a = a.clone();
let b = b.clone();
let c = c.clone();

check

let (a, b, c) = (a.clone(), b.clone(), c.clone()); // not (a, b, c).clone(), because that would move then clone

Of course, this isn't shorter, and rustfmt could spread it across multiple lines, but your solution still isn't as nice as making users do nothing (like my proposal in original post) either. The original post was about not making users do a .clone() (or honk!, or something else) on every usage, and your example is the same thing as a regular clone but shorter. Not to mention - if users desire this macro, they already can copy that piece of code into their own code, without adding any maintenance burden upon Yew.

Also see yewstack/implicit-clone#39 and links mentioned in original post (clown, Rust RFC, and probably more can be found on the internet, I was shown a really nice library over Yew's Discord which also tries to solve this issue but I do not remember it right now).