Improve `block2`

[madsmtm]

I haven't given this crate nearly as much love as it deserves!

In particular, it would be nice to allow mutating blocks, e.g. FnOnce and FnMut should become BlockOnce and BlockMut.

Also, I'm not certain the way ConcreteBlock is put on the stack is sound? And what about lifetime of the stuff used in the closure?

Issues in block

• Examples! SSheldon/rust-block#5
  • Included in Change syntax for blocks, and allow them to carry a lifetime #569.
• Add tests with multiple parameters. SSheldon/rust-block#6
  • Done in 8a723c1.
• Need to copy the block SSheldon/rust-block#9
  • Fixed in Fix block2 memory management #568.
• License File SSheldon/rust-block#13
  • Fixed by moving into this repo (which has a license file).
• Support for using the GNUstep blocks runtime SSheldon/rust-block#2
  • Fixed in Add sys crate for blocks #49
• Update test_utils to use cc rather than gcc. SSheldon/rust-block#8
  • Included in Move block crate into this repo #18.
• Block should be able to take FnMut, as opposed to just Fn SSheldon/rust-block#12
  • Moved to Allow FnMut in blocks? #571.
• add MIT license file SSheldon/rust-block#14
  • Fixed by moving into this repo (which has a license file).
• block2 0.2.0-alpha.6: Implementing Encode/RefEncode is bothersome and not always possible SSheldon/rust-block#16
  • Answered
• Don't box block descriptors SSheldon/rust-block#17
  • Fixed.
• Add apple tvos support SSheldon/rust-block#18
  • Fixed.

Work on this in other projects

• cidre's blocks
• blocksr

[madsmtm]

BlockOnce, or whatever it will end up as, should try to (when debug assertions are enabled) ensure that it is actually only called once.

[madsmtm]

I'm starting to suspect that the naive approach of adding BlockMut/BlockOnce is actually a bad idea, and that we instead should be looking at Swift block semantics instead.

The following attributes affect blocks in particular:

• clang's noescape, opposite of Swift's @escaping (the default is escaping).
• Swift's @Sendable (the default is non-sendable).
• clang's _Nullable_result, only used for async support so not relevant yet.

Which seem to suggest that maybe we should instead have these four: Block, EscapingBlock, SendableBlock, EscapingSendableBlock?

[madsmtm]

@escaping is basically exactly equivalent to a 'static bound on the closure.

Although, escaping closures can’t capture mutable references, while non-escaping closures can, so maybe we can allow FnMut for non-escaping closures? Except Swift's capturing rules are a bit different, seems like escaping closures sometimes actually can capture mutable references?

[madsmtm]

I think we do want some way to have FnOnce-like blocks, it is a very common pattern.

E.g. basically all completionHandler:'s are FnOnce + 'static, they're just only attributed as @escaping. So we'll have to enrich framework data again sigh

[madsmtm]

Send + Sync vs. @Sendable:

A impl Fn() + Sync can easily be turned into impl Fn() + Send or impl Fn() + Send + Sync, while the opposite is not true. So impl Fn() + Sync is more restrictive on the user, but might not be necessary? The few Objective-C APIs that use NS_SWIFT_SENDABLE blocks seem like they only use the block from a single thread at a time; though to be safe, we'll probably have to be overly strict here.

[madsmtm]

Design idea:

struct Inner<'a, A, R, F> { ... }

pub type Block<'a, A, R> = Inner<A, R, dyn FnMut(A) -> R + 'a>;
pub type BlockMut<'a, A, R> = Inner<A, R, dyn FnMut(A) -> R + 'a>;
pub type BlockOnce<'a, A, R> = Inner<A, R, dyn FnOnce(A) -> R + 'a>;

pub type BlockSend<'a, A, R> = Block<A, R, dyn Fn(A) -> R + Send + 'a>;
// And so one for `BlockSendMut`, `BlockSendOnce`, `BlockSync`...

fn takes_sendable_block(block: &BlockSendSync<'static, (u32,), u8>) {}
fn takes_noescape_block(block: &Block<'_, (u32, u32), u32>) {}
fn takes_mutating_block(block: &mut BlockMut<'static, (), ()>) {}

This is kinda nice since we avoid a proliferation of traits that way.

Though reconsidering, maybe we can actually make it as simple as:

struct Block<F> { ... magic ... }

fn takes_sendable_block(block: &Block<dyn Fn(u32) -> u8 + Send + Sync>) {}
fn takes_noescape_block(block: &Block<dyn Fn(u32, u32) -> u32 + '_>) {}
fn takes_mutating_block(block: &mut Block<dyn FnMut()>) {}

That way, we should be able to support all possible configurations, and then we can let icrate/header-translator figure out which one is actually safe for a given function.

[madsmtm]

EDIT: Moved to #573.