- Feature Name: `struct_closure`
- Start Date: 2022-08-05
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

Concrete Closure Types

# Motivation
[motivation]: #motivation

This proposal exists entirely out of spite for the `char::is_ascii*` family of
functions.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

Closures in Rust are represented by the struct `core::ops::Closure`, while
callables are represented by the traits `Fn`, `FnMut` and `FnOnce`. This
enables closures to participate specially in trait resolution, and be
distinguished from other types of callables (particularly user-defined ones).

In general, when writing generic code, it is preferred to use the `Fn*` traits.
However, in some edge-cases it can be useful to use `Closure` or even both.

## Examples

The main user of the `Closure` struct is `Pattern`:

```rust
fn takes_char(x: char) -> bool {
    true
}

fn takes_char_ref(x: &char) -> bool {
    true
}

// these both work:
"hello".trim_start_matches(takes_char);
"hello".trim_start_matches(takes_char_ref);
```

This wouldn't be possible if `Pattern` were instead relying on the traits,
as it's entirely possible for a type to implement multiple `Fn` traits, but a
closure will never do so.

Due to historical reasons, `char` provides some functions that take `&self` and
some which take `self`:

```rust
char::is_ascii(&'a');
char::is_numeric('9');
```

and they both work as `Pattern`, thanks to `Closure`:

```rust
"hello".trim_start_matches(char::is_ascii);
"hello".trim_start_matches(char::is_numeric);
```

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

Currently the `Fn*` traits are pretty unstable, including their internal
representation. This proposal simply introduces a new, special lang item:

```rust
#[rustc_paren_sugar]
#[lang="closure"]
struct Closure<F: FnOnce<Args>, Args> {
    // compiler special...
}

impl<F, Args> Fn<Args> for Closure<F, Args> where F: Fn<Args> {
    // details omitted...
}
impl<F, Args> FnMut<Args> for Closure<F, Args> where F: FnMut<Args> {
    // details omitted...
}
impl<F, Args> FnOnce<Args> for Closure<F, Args> where F: FnOnce<Args> {
    // details omitted...
}
```

Some things to note: The details of `Args` are subject to change. This proposal
relies on that, because otherwise this cannot have the correct `for<'a>`
bounds. This proposal does not define the details of `Args`, but suggests they
might be of `fn` type. (Indeed, it would be easiest to implement this by
defining `Args` to be an `fn` type. Tho do note the `Args` in `Closure` does
not need to be the same `Args` in `Fn*`, as long as the compiler knows how to
map between them.)

In general, it'd be awkward to use this in a function. Consider:

```rust
fn foo<F: Fn...>(closure: Closure<F, ...>)
```

It's much simpler to just use F directly. But in a trait, things are different,
because you can't have multiple generic impls like that, so it actually becomes
useful:

```rust
// this DOES NOT WORK
impl<F: FnMut(char) -> bool> Pattern for F { ... }
impl<F: FnMut(&char) -> bool> Pattern for F { ... }

// but this would, because these types don't overlap
impl<F: FnMut(char) -> bool> Pattern for Closure<F, fn(char) -> bool> { ... }
impl<F: FnMut(&char) -> bool> Pattern for Closure<F, fn(&char) -> bool> { ... }
```

This is, for all intents and purposes, a "zero-cost" wrapper over
closures (except for one layer of type system nesting); and unlike `fn` types,
it doesn't incur the additional pointer overhead, being the same size as the
underlying closure.

Additionally, as this is the main goal of the RFC, we add the following impl to
`Pattern`:

```rust
impl<'a, F> Pattern<'a> for Closure<F, fn(&char) -> bool>
where
    F: FnMut(&char) -> bool,
{
    pattern_methods!(CharRefPredicateSearcher<'a, F>, MultiCharEqPattern, CharRefPredicateSearcher);    
}
```

Which, for all intents and purposes, is the same as the existing generic impl,
except with `&char` instead of `char`.

# Drawbacks
[drawbacks]: #drawbacks

- Small extra cost due to additional wrapper type. This could affect existing
    users of closures with longer compilation times, but it shouldn't affect
    runtime performance.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

This proposal intentionally distinguishes closures from other kinds of
callables, solely to fix the issue with our beloved `char::is_ascii*` family of
functions. Given that the sole reason for this proposal is to fix that issue,
there's actually a huge range of possible alternatives. These are a few
examples:

- We might be able to `impl Pattern for fn(&char) -> bool`. This does raise the
    question of whether we *want* non-closure types which happen to be callable
    with a bare `char` and return a `bool` to also be usable as a `Pattern`, or
    only "true" closures. It also raises the question of whether we want to
    accept closures which take `&char`, or only functions. This has not been
    discussed previously. See unresolved questions.

    This proposal rejects this alternative by principle: If `Pattern` works on
    `(char) -> bool` closures (*including* `(char) -> bool` functions), and
    `(&char) -> bool` functions, it creates an inconsistency where
    `(&char) -> bool` closures don't work for seemingly no good reason.
- There have been past discussions about potential "overlapping impls" as a way
    of solving this, but they never got very far and were quite underspecified.
    This proposal is much narrower in scope, so it shouldn't have those issues.
- Adding `std::char::is_ascii*` which take `char` is fragile at best.

# Prior art
[prior-art]: #prior-art

Tentatively, the way function pointers work today is the prior art.

# Unresolved questions
[unresolved-questions]: #unresolved-questions

1. This proposal raises the question of whether we want non-closure callables
    to be `Pattern`. Note that, today, it is not possible to specialize
    `Pattern` for such callables.

    This can be resolved before stabilization: this proposal allows either
    option to be chosen, e.g.:

    ```rust
    // any (char) -> bool callable
    impl<F: FnMut(char) -> bool> Pattern for F { ... }
    // only (&char) -> bool closures
    impl<F: FnMut(&char) -> bool> Pattern for Closure<F, fn(&char) -> bool> { ... }
    ```

    or even with specialization:

    ```rust
    // any (char) -> bool callable (specializable)
    impl<F: FnMut(char) -> bool> Pattern for F { ... }
    // only (char) -> bool closures
    impl<F: FnMut(char) -> bool> Pattern for Closure<F, fn(char) -> bool> { ... }
    // only (&char) -> bool closures
    impl<F: FnMut(&char) -> bool> Pattern for Closure<F, fn(&char) -> bool> { ... }
    ```
2. This proposal changes type inference for closures. Specifically, adding
    `impl<F: Fn(&char) -> bool> Pattern for Closure<F, fn(&char)>` would break
    inference for existing users of `str.matches(|x| x.whatever)`, tho this is
    not that big of a deal, as the edition machinery can handle this today, in
    a similar way to how it can handle `IntoIterator` for arrays. But the
    unresolved question is whether we want to define new stability rules for
    trait impls on closures.

    Today, Rust mostly considers new trait impls to be non-breaking, but with
    workarounds for where such impls cause major ecosystem breakage (arrays).
    Should new impls for Closure where there was once only one be considered a
    breaking, must-never-do change, such as in the case of `Pattern`, or should
    the user be responsible for annotating the closure? This should be resolved
    before merging this RFC. (Or, indeed, this RFC should be rejected if any of
    this is unacceptable - after all, the proposal sets out to solve `Pattern`
    for the `char::is_ascii*` family of functions, and this would prevent
    that.)
3. The `Args`. Just like for `Fn*`, this must be resolved before stabilization.

# Future possibilities
[future-possibilities]: #future-possibilities

N/A.