Getting `&T` to work in blocks

[madsmtm]

Ideally, we'd be able to write:

pub fn takes_block(block: &Block<dyn Fn(&NSString) + '_>) {
    let string = NSString::from_str("foo");
    block.call((&string,));
}

And call that with:

takes_block(&RcBlock::new(|string| {
    println!("{string}");
}));

Currently, we map such blocks with NonNull<NSString> instead, and users must do unsafe { string.as_ref() } before accessing it.

You'd think that the impl<T> IntoBlock<dyn Fn(T)> for Fn(T) { ... } that we currently have would be enough, but unfortunately, the lifetime in fn(&T) is higher-ranked, Fn(&T) desugars to for<'a> Fn(&'a T). Ideally, we'd instead write something like impl IntoBlock<dyn for<T> Fn(T)> for for<T> Fn(T), i.e. make T higher-ranked, but that's an incomplete feature in the compiler, so likely a long ways away from being possible.

Also discussed in #168, the solution that cidre goes with is unsound IIRC.

[madsmtm]

One option that I can think of would be to change the signature of blocks to Block<'a, Args, Return> (i.e. &Block<'_, (&NSString,), ()>).

The problem with this is that it's unsound, as the lifetime of the &NSString is controlled by the caller (and could thus be extended beyond the lifetime of the function call). For example (playground):

fn takes_block(block: &Block<'_, (&NSString,), ()>) {
    let y = String::from("test");
    block.call((&y,));
}

// Errors with "`string` does not live long enough".

To be clear, it could be "exploited" with:

let mut grabbed_string = Cell::new(None);
takes_block(&RcBlock::new(|string: &NSString| {
    grabbed_string.set(Some(string));
}));
let s = grabbed_string.get().unwrap();
println!("{s:?}"); // Lifetime of string extended beyond block

And we must ensure in the signature when mapping a function like NSArray::enumerateObjectsUsingBlock that this can't happen.

[madsmtm]

Another option would be to automatically retain all retainable objects before handling them out to the caller. Something like:

fn takes_block(block: &Block<dyn Fn(Retained<NSString>) + '_>) { ... }

The problem with that is that it's inefficient: if you're only going to use the item inside the block (which is the common case), then you don't need the retain, and we really shouldn't be doing it for you.

[madsmtm]

A third option is to add extra impls for &T. This hits rust-lang/rust#56105, and leads to a combinatorial explosion in the number of implementations if we want to support multiple parameters (for two parameters we'd need to implement for Fn(T, T), Fn(T, &T), Fn(&T, T) and Fn(&T, &T)). There is no way to do this more generically without further language support (trust me, I've tried!)

wasm-bindgen currently just allows coherence_leak_check and does it anyhow for 1-argument closures, see:
https://github.com/wasm-bindgen/wasm-bindgen/blob/7a7c4032eb571d344b3832b04fab5e62d0db7634/src/convert/closures.rs#L476-L490

[madsmtm]

If we go with the path of just #[allow(coherence_leak_check)], the question becomes: Which impls should we add?

Under the suspicion that we could get far with a limited number of implementations, I classified all current &Block usage in generated framework crates. Note that there's three distinct argument kinds, and we'd need separate impls for each of these: T, &T and Option<&T>. (&mut T is very rare).

Data

# blocks	Signature kind
889	fn(&T)
741	fn()
652	fn(Option<&T>)
550	fn(Option<&T>, Option<&T>)
343	fn(T)
251	fn(&T, Option<&T>)
192	fn(&T, &T)
173	fn(T, Option<&T>)
127	fn(&T, T)
121	fn(T, T)
106	fn(&T, &T, &T, &T)
94	fn(&T, &T, &T)
83	fn(&T, T, T)
58	fn(Option<&T>, Option<&T>, Option<&T>)
49	fn(T, T, T, T)
47	fn(&T, &T, T)
39	fn(&T, Option<&T>, Option<&T>)
26	fn(T, &T)
24	fn(&T, T, Option<&T>)
19	fn(Option<&T>, Option<&T>, T, T, T)
17	fn(T, T, T, T, T)
16	fn(T, T, T)
14	fn(&T, T, &T)
14	fn(Option<&T>, Option<&T>, T)
13	fn(Option<&T>, T, Option<&T>)
12	fn(T, T, Option<&T>)
9	fn(&T, T, T, T, T)
8	fn(Option<&T>, T, T)
8	fn(&T, T, T, T)
8	fn(T, Option<&T>, T, Option<&T>)
7	fn(Option<&T>, T)
7	fn(T, T, &T, T)
7	fn(T, T, T, T, T, T)
6	fn(T, Option<&T>, T)
6	fn(&T, Option<&T>, T, Option<&T>)
6	fn(Option<&T>, Option<&T>, T, Option<&T>)
5	fn(T, &T, Option<&T>)
5	fn(T, &T, T)
5	fn(&T, &T, T, T)
5	fn(Option<&T>, T, T, T)
5	fn(T, T, Option<&T>, Option<&T>)
5	fn(T, T, T, T, T, Option<&T>)
4	fn(&T, &T, Option<&T>)
4	fn(Option<&T>, &T, Option<&T>)
4	fn(T, T, Option<&T>, &T)
4	fn(&T, Option<&T>, Option<&T>, Option<&T>, Option<&T>)
3	fn(Option<&T>, &T)
3	fn(&T, Option<&T>, Option<&T>, Option<&T>)
3	fn(&T, T, &T, &T)
3	fn(&T, T, &T, T)
3	fn(&T, T, T, Option<&T>)
3	fn(Option<&T>, T, Option<&T>, Option<&T>)
3	fn(&T, &T, T, T, T)
3	fn(&T, Option<&T>, Option<&T>, T, Option<&T>)
3	fn(T, T, Option<&T>, T, T)
2	fn(Option<&T>, &T, T)
2	fn(T, &T, &T)
2	fn(T, T, &T)
2	fn(&T, &T, T, &T)
2	fn(&T, T, &mut T, &mut T)
2	fn(Option<&T>, &T, Option<&T>, T)
2	fn(Option<&T>, T, T, &T)
2	fn(Option<&T>, T, T, Option<&T>)
2	fn(T, &T, T, T)
2	fn(T, T, Option<&T>, T)
2	fn(Option<&T>, Option<&T>, Option<&T>, T, Option<&T>)
2	fn(Option<&T>, T, Option<&T>, T, Option<&T>)
2	fn(T, Option<&T>, T, T, Option<&T>)
2	fn(T, T, &T, T, T)
2	fn(T, T, T, &T, &T)
2	fn(T, T, Option<&T>, Option<&T>, T, T)
1	fn(T, Option<&T>, Option<&T>)
1	fn(&T, Option<&T>, &T, Option<&T>)
1	fn(Option<&T>, Option<&T>, Option<&T>, Option<&T>)
1	fn(Option<&T>, Option<&T>, T, &T)
1	fn(T, &T, &T, T)
1	fn(T, T, &T, Option<&T>)
1	fn(&T, T, T, T, Option<&T>)
1	fn(Option<&T>, Option<&T>, T, T, Option<&T>)
1	fn(Option<&T>, T, T, T, Option<&T>)
1	fn(T, T, &T, &T, Option<&T>)
1	fn(&T, Option<&T>, Option<&T>, Option<&T>, T, Option<&T>)
1	fn(&T, T, T, T, T, T)
1	fn(T, T, T, &T, &T, Option<&T>)
1	fn(Option<&T>, T, T, T, T, T, Option<&T>)

Grouping a bit per number of arguments:

# arguments	# blocks	Out of total	Impls
0	741	15.24%	1
1	1884	38.76%	3
2	1450	29.83%	9
3	453	9.32%	21
4	243	5.00%	28
5	72	1.48%	16
6	17	0.35%	6
7	1	0.02%	1

If we wanted a consistent document-able rule like "for up to N arguments, IntoBlock is also implemented for &T and Option<&T>", the number of impls we'd need is 3^N.

---

I'm leaning towards supporting up to 2 arguments, and keep emitting NonNull<T>/*mut T for the rest? That would only require 10 extra impls, would be documentable, and would allow ~80% of blocks to be pointer-free, which is probably good enough?

Supporting up to 3 arguments would get us up to ~90%, but at the cost of a bunch more impls (20, or 26 if we wanted to implement all combinations for docs).