Extending deref/index with ownership transfer: DerefMove, IndexMove, IndexSet

[nikomatsakis]

It is clear that there is a need for the ability to move out of smart pointers and indexable things (DerefMove, IndexMove). The other frequently desired option is to IndexSet, which would be a special-cased version for indexing in this situation:

map[key] = value

currently, this is handled via IndexMut, but that is sub-optimal, because if the key is not already part of the map, the result is a panic.

Basic plan

DerefMove/IndexMove/IndexSet should layer on top of the traits we have now. One needs to be careful here because of subtle interactions with autoref and so forth.

Postponed RFCs

• RFC: Add DerefMove #178
• Introduce remaining Index traits #159
• IndexAssign: overloading the a[b] = c expression #1129 (map[key] = value)

[tomjakubowski]

I'd like DerefMove for similar reasons that Servo wants it: servo/servo#3868

Namely, I have an type Foo, which owns a raw pointer from a crate that has FFI bindings:

struct Foo {
    handle: my_ffi_crate::foo // foo is a *mut to an uninhabited enum
}

and a "borrowed" version of that called BFoo:

struct BFoo<'a> {
    handle: my_ffi_crate::bfoo, // bfoo is the *const equivalent of my_ffi_crate::foo
    _phantom: PhantomData<&'a Foo>
}

Foo is the Rust equivalent of a type in the C library that's a flexible data storage type: think something like a C type that works like JSON. The C library supports things like: list indexing, map lookup, etc. which, in the Rust crate, have signatures like fn get<'a>(&'a self, key: Key) -> BFoo<'a>.

Most of the immutable "accessor" methods of Foo have to be implemented for both Foo and BFoo<'a> (a map might be from keys to more maps), which is annoying. It would make sense, I believe, to implement DerefMove<Target=BFoo<'a>> for &'a Foo, and then just implement those methods on BFoo<'a>. Of course, that might also require some additional autoref/autoderef magic.

[thepowersgang]

A potential problem for the design of DerefMove - How would unsized types be handled? (e.g. FnOnce)

[Gankra]

Missing from this list is also IndexGet, which is the "returns a value" version of Index.

[pnkfelix]

@gankro what is the difference between your IndexGet versus the IndexMove in the list ?

[Gankra]

Ah I assumed IndexMove took self by-value (given the comparison to DerefMove), but if it takes &mut self, then never mind.

[flying-sheep]

what does the RFCs being postponed mean? will they simply be back on track as soon as someone has made up a coherent idea of how everything should play together and writes it up?

[steveklabnik]

@flying-sheep it means "we're not rejecting this RFC because it's bad, now is just not the right time." This happened a lot before 1.0, so we could focus on what needed to ship in 1.0.

And yes, if there's a postponed RFC, someone needs to go through and evaluate if it's still valid in its current form, or update it, and re-submit it.

[flying-sheep]

i’m glad that IndexGet/IndexMove will be a thing.

things like ndarray profit from it. generally, all data structures where “slice” views can’t be rust slices.

should i try to update the “remaining Index traits” RFC (#159)?

if so:

• which name? the IndexRef/IndexValue train is gone, and @gankro was confused by IndexMove, so maybe IndexGet?
• better do index_set as default-implemented trait for IndexMut or in a dedicated IndexSet?
• also merge in IndexAssign (IndexAssign: overloading the a[b] = c expression #1129)?

[andrewcsmith]

I would say that IndexGet is the clearest, because of the ease of implementing it for both T and &T. IndexMove is too restricted as a name, in that you might not actually want to move anything, but instead you might want to copy.

Perhaps it would be possible to use type inference to decide whether to use Index or IndexGet. Example:

let some_array: [i32; 4] = [1, 2, 3, 4];
let some_slice = &some_array[0..3];
let x = some_slice[2]; // x: &i32 (default behavior)
let y: i32 = some_slice[2]; // y: i32 (would use `IndexGet` to pass by value

This would more or less follow from the current inference of IndexMut.

I do see the potential for compiler confusion in choosing which trait to use for a given operation, but I would at least appreciate a default implementation of IndexGet<E, R> for &[R] where R: Copy. Syntactic sugar ([E]) aside, this would let us assume that slices would be acceptable, and additional implementors of IndexGet could define their own behavior (whether they want to copy, clone, whatever).

I would also like to mention that even though copying-when-indexing is antithetical to C/C++, it is a very common idiom when it comes to Ruby, etc. I don't think this is a weakness in Ruby, but in fact allowing the end-user to use one idiom or other other should help ease the learning curve for people coming from dynamic languages that assume copy.

One of my greatest frustrations with the Ruby language is not knowing whether array indexing was happening by-value or by-reference. I think if Rust could acknowledge both of these domains, and allow programmers the explicit option of choosing one or the other, it would go a long way.

Edit: thanks @comex for pointing out that I indexed a stack array rather than a slice initially

[comex]

@andrewcsmith some_slice[2] is already i32 - you need &some_slice[2] for &i32. The indexing operator carries an implicit dereference.

(some_slice is also not a slice...)

[VFLashM]

Theory

Both deref and index are for types containing values of other types. They allow to conveniently access contained value.
The main difference is that deref types usually contain only one instance of other type, while index types usually contain multiple instances.
There are actually many ways to access internal instance, and index/deref families should cover most of them.

There are two cases currently supported:

(1) accept ref, return ref (Deref/Index)
(2) accept mut ref, return mut ref (DerefMut,IndexMut)

There is one case requested for derefs:

(3) consume value, return value (DerefMove?,IndexMove?)

It's an open question whether or not we need Index counterpart. I personally don't think it will be very useful.

There are two more index cases requested:

(4) accept ref, return value (IndexGet?)
(5) accept mut ref, accept value, set value (IndexSet?)

They can be used for collections not actually storing value instances (e.g. bit array setting/returning bools).
Case 5) can also be used to insert new values to hashmaps, which I think is a highly desirable feature.
These cases apparently do not need deref counterparts.

Practice

Now let's get to practice, and please correct me if I'm wrong about current rules.
Here I assume that S is source type, T is target type and I is index type. s, t and i will be corresponding instances.

Deref

Current deref rules

Current manual deref follows simple rules:

1. &*s- perform Deref
2. &mut *s - perform DerefMut
3. *s and S is Copy - perform Deref and copy
   Note that if there is no DerefMut and S is Copy, then &mut *s fails, but &mut {*s} succeeds.
   If T is not Copy, then *s will fail. Copyability of S does not matter.

Autoderef follows the same rules, but also depends on context:

1. If context needs &T - perform Deref
2. If context needs &mut T - perform DerefMut
3. If context needs value of T and T is Copyable - perform Deref and copy.
   Note that rule autoderef rule 3) is somewhat inconsistent, it works for self in method calls, but does not work for arguments in function calls.
   If context needs value and T is not Copy, then it fails. Copyability of S does not matter.

Proposed deref rules

Deref rules proposed in #178, in short, are: try to move copyables, try to ref non-copyables, otherwise use whatever possible.
I do mostly agree with the proposed rules, but don't really like 'use whatever possible' part.
#178 says that, for example, if there is no Deref, but DerefMove, then it should be used for all derefs.
Let's imagine that there is no Deref, but T is Copy. In this case &*s would perform DerefMove and take reference of the result, which is both non-intuitive and contradicting with how Deref currently works (see my note about missing DerefMut).
I'd say it's better to fail in this case. Another, even simpler option is to make Deref implementation mandatory for types implementing DerefMove. I think it's reasonable and makes everything easier.

Proposed manual deref rules:

1. &*s - perform Deref
2. &mut *s - perform DerefMut
3. *s and S is Copy and implements DerefMove - copy source and perform DerefMove
4. *s and T is Copy and S implements Deref - perform Deref and copy result
5. *s and neither 3) or 4) apply - perform DerefMove

Proposed autoderef rules:

1. If context needs &T - perform Deref
2. If context needs &mut T - perform DerefMut
3. If context needs value of T, S is Copy and implements DerefMove - copy source and perform DerefMove
4. If context needs value of T, T is Copy and S implements Deref - perform Deref and copy result
5. If context needs value of T, but neither 3) or 4) apply - perform DerefMove

If rule condition is satisfied, but required trait is not available, then that's a failure and compiler should not try to apply other rules (that's the only thing different from #178)

It is possible to support DerefGet/DerefSet, but, then again, it's noticeably ramps complexity and likely not very useful.
If needed, DerefGet/DerefSet should follow strategy for IndexGet/IndexSet described below.

Indexing

Current indexing rules

Indexing is more or less follow deref, but is generally simpler, because there is no autoderef counterpart.

Current rules for indexing:

1. &s[i] - perform Index
2. &mut s[i] - perform IndexMut
3. s[i] and T is Copy - perform Index and Copy
   If T is not Copy, then s[i] will fail.

Proposed indexing rules

This extends both #159 and #1129, adds more details and answers some unresolved questions.

Main problem is IndexGet. Option of having it adds lots of ambiguity into rules.
Also, possiblity of different implementation of Index and IndexGet scares me.
I think that if collection need IndexGet, then having Index/IndexMut/IndexMove does not make sense.

I propose to make IndexGet and Index/IndexMut/IndexMove mutually exclusive.
Types implementing IndexGet can have automatically generated default implementation of Index/IndexMove for trait compatibility purposes, but manually implementing Index/IndexMut/IndexMove should be forbidden.

With mutually exclusive IndexGet and Index/IndexMut/IndexMove, indexing rules actually become pretty simple.

For types implementing IndexGet:

1. s[i] - perform IndexGet
2. s[i] = expr (asssignment) - perform IndexSet
3. s[i] += expr (compound assignment) - perform IndexGet, apply non-compound operation, then IndexSet result
   With these rules &s[i] and &mut s[i] are still possible, but they represent references to temporary value returned by IndexGet. Note that it differs from the way Deref works, but I think it worth it. For deref it is not as useful because autoderef can handle most of function interface compatibility issues. Indexing does not have autoderef counterpart and therefore it's not wise to prohibit taking references.

For all other types:

1. &s[i] - perform Index
2. &mut s[i] - perform IndexMut
3. s[i] = expr (asssignment) - perform IndexSet (note that it should NOT fallback to IndexMut)
4. s[i] += expr (compound asssignment) - perform IndexMut, apply compound operation on it's result (note that it should NOT fallback to IndexSet)
5. s[i] and T is Copy - perform Index and Copy
6. s[i] and T is not Copy - perform IndexMove

Just like with derefs, if rule condition is satisfied, but required trait is not available, then that's a failure and compiler should not try to apply other rules.

Note that I'm not sure if we need IndexMove (consume value, return value), but I list it here for completeness sake.

Indexing examples

// Bits is a tightly packed bits array, implements IndexGet/IndexSet
println!("first bit is: {}", bits[0]); // bits.index_get(0)
bits[1] = true; // bits.index_set(1, true)
bits[2] ^= true; // bits.index_set(2, (bits.index_get(2) ^ true))
let tref = &bits[3] // &bits.index_get(3), reference to temporary

// Array implements Index/IndexMut/IndexSet
println!("first element is: {}", array[0]) // *array.index(0)
let second = &array[1] // array.index(1), ref of second element
let third = &mut array[2] // array.index_mut(2), mutable ref of third element
array[3] = 2; // array.index_set(3, 2)
array[4] += 3; // (*array.index_mut(4)) += 3

// Map implements:
//   Index/IndexMut for Index types where Key impl Borrow<Index>
//   IndexSet/IndexMove for Index types where Key impl From<Index>
let vref = &array["key"] // array.index("key"), ref of value
let vrefmut = &mut array["key"] // array.index_mut("key"), mutable ref of value
map["new key"] = 1; // map.index_set("new key", 1), creates new entry
map["new key"] += 2 // (*map.index_mut("new key")) += 2, modifies existing entry
return map["key"]; // map.index_move("key"), consumes map
// failures:
&map["missing key"] // map.index("missing key"), fails
&mut map["missing key"] // map.index_mut("missing key"), fails
map["missing key"] += 2 // (*map.index_mut("missing key")) += 2, does not insert value, fails

P.S.

• It's the longest comment I've ever wrote
• If necessary, I can create a new rfc with even more implementation details
• Or I can start hacking, you know =)

[spiveeworks]

In the case of indexing, what would happen to
s[i].do(), for some impl T {fn do(&self);}?

would it become
s.index_move(i).do() by rule 6
or perhaps worse
s.index(i).clone().do() by rule 5, where clone has the Copy implementation

obviously it would be nice if it became (&s[i]).do()

[VFLashM]

Wow, it's been a while.

You're absolutely right, that's a very important use case I missed.

I guess rules have to be modified like this to make it work:

1. &s[i] or s[i].method(...) where method needs &self - perform Index
2. &mut s[i] or s[i].method(...) where method needs &mut self - perform IndexMut
3. ...

I hate to see how complex it gets, but still can't find a more usable solution.

[chpio]

The same goes for Borrow. The Borrow trait is pretty useless as it is now. It even needs a workaround in the language to work for &[] and &str as the conversion creates a (hidden) new type.

• Borrow
• Deref

[coder543]

Given that we're in the impl Period, is there any motion to make forward progress on this? In addition to the heavily discussed stuff, this issue seems to be a blocker for things like Box<FnOnce> which have been a sore spot for years now.

I also don't see a clear summary of what is blocking this, in case someone wanted to hack on this, which I think means the design work was never completed? Just trying to get a feel for the situation.

[burdges]

IndexGet plus IndexSet should not be invoked together, say by s[i] += ... It'd become a nightmare for performance when using larger numerical types, like even 256 bits, which may or may not be copy.

A priori, I'd think indexing into collection types should return Entry/Guard like types that provide access to the memory using DerefMut or DerefMove, whatever that looks like. Adding this IndexGet and IndexSet zoo sounds problematic, especially when HashMap's Entry took so much effort to hammer out recently.

[vorner]

Hello. I'd like this to move forward (especially because of Box<FnOnce>). Is there anything I could do to help to move forward?

[tema3210]

What if we do traits like so:

trait DerefMove: Deref {
   fn deref_move(self)->Self::Target;
}
//used by `let item: !Copy = map[index]`
trait IndexMove<Idx: ?Sized>: IndexMut<Idx> {
   fn index_move(&mut self,index: Idx) -> Self::Output; //is supposed to remove moved item from indexed collection(?)
}

///Used by this `map[index] = item` unwraps an error, fallback to `IndexMut`
trait IndexSet<Idx: ?Sized>: IndexMut<Idx> {
   fn index_set(&mut self,index: Idx,val: Self::Output) -> Result<(),Error>; //some error, maybe OOM, or index is already set.
}

DerefMove is needed for matching internals of Box's and co.

fn main() {
   let arc = Box::new("Hello".to_string()); //for example
   match arc {
      box string => {}//used to be
      *string => {} //now
   }
}

[bjorn3]

Your DerefMove is not equivalent to how Box implements this and won't work for Box<dyn FnOnce()>. In case of Box the box is deallocated once it goes out of scope, but can be moved out earlier. For unsized values like dyn FnOnce() in the FnOnce() for Box<dyn FnOnce()> impl it is necessary that the Box is not deallocated when "moving out" as the unsized value is represented as pointer to the Box contents. Your DerefMove trait would require returning unsized values to work, which is a really hard problem to solve.

[tema3210]

Another variant I imagine:

trait DerefMove: Deref {
   fn deref_move(&mut self) -> Self::Output;

   fn drop_empty(&mut self);
}

Reasons:

• We still need to drop container somehow: plain Drop::drop would almost(?) always be incorrect;
• So we need a special way to dispose an empty container and here it is.

Two more points:

• First is that, because we move a value out from a container it may no longer be used - it has to go of scope;
• Second is that when we introduce deref move patterns the following no longer obvious:

let a = String::new();
match (a,1) {
   (bnd,1) => ... // which type does `bnd` has? `String` or `str`?
   ...
}

One solutions is to make an exception in match ergonomics and deref patterns interaction, so that bnd would definitevely be a String.
Another one is new kind of patterns.

[tema3210]

Your DerefMove is not equivalent to how Box implements this and won't work for Box<dyn FnOnce()>. In case of Box the box is deallocated once it goes out of scope, but can be moved out earlier. For unsized values like dyn FnOnce() in the FnOnce() for Box<dyn FnOnce()> impl it is necessary that the Box is not deallocated when "moving out" as the unsized value is represented as pointer to the Box contents. Your DerefMove trait would require returning unsized values to work, which is a really hard problem to solve.

I see, but due to that inability, are dyn Sized types the only ones that cannot, actually, be moved? By that what we actually want from DerefMove is really some sound form of reinterpret_cast? Like, when we move dyn FnOnce out of its Box some reinterpretation of the box is what is actually happening.

[tema3210]

Alternatively, we split DerefMove into two traits:

/// trait for moving out of container
trait DerefGet: Deref {
   /// This return layout info of data stored by container
   fn layout(&self) -> Layout;
   /// This returns an actual data pointer. Also, `Unique` from `core::ptr` may be used here.
   fn deref_get(&self) -> *const <Self as Deref>::Target;
   /// This is intended to dispose **empty** container
   unsafe fn drop(*mut self);
}

///trait for moving in a container
trait DerefSet: DerefMut {
   /// prepare the memory region
   fn prepare(&mut self,layout: Layout);
   /// move the value in. Here I would like to use `Unique` too.
   fn deref_set(&mut self,*mut <Self as Deref>::Target);
}

And the interesting part:

...
let data: Box<[u64]> = ...;
let mut data_moved = Box::new();
*data_moved = *data; // tada! [1]
//let data_moved = box *data //this woun't work as of there is no thing which we `DerefSet` yet. [2]
...

[1] What is actually happening is:

• dereference operator calls layout, gets it, and calls recievers prepare with the desired layout. container itself decides how to manage its memory, for example, Box has two options: reallocate and reallocate_in_place... ;
• after that we get the pointer from data by deref_get and pass in to deref_set of data_moved;
• the final thing to do is to dispose data, but because of one of containers fields has been moved out, for soundness it needs a different drop path, which is unsafe fn drop(*mut self) from DerefGet is.

[2] If we go that far, we face the need of Placer trait and placement features, exactly as it used to be in past...

The problem of fallible allocation (can be probably be found when DerefSetting smth. like [1;10*1024*1024*1024]) is still there, however:

• The vast majority of use cases deal with Sized data => Layout returned from DerefGet::layout is going to be a const.
• Also, I don't see any adequate way to support fallible allocation without some crazy syntax and some kind of opinionated signaling involved; given the previous bullet I don't think that in such case we need to do anything else than a panic or handle_alloc_error.

A Sized data example

let mut b: Box<[u8;10]> = ...;
*b = [10;10]; //Here we used `DerefSet`, layout passing is optimized out.

Internals thread

[86maid]

Is this problem unsolvable?

[nyabinary]

Whats the status?

[Jules-Bertholet]

For IndexAssign, maybe instead of being a separate trait, it can be a new method of IndexMut, with a default impl?

[programmerjake]

For IndexAssign, maybe instead of being a separate trait, it can be a new method of IndexMut, with a default impl?

that doesn't work for HashMap because it would require implementing IndexMut which requires coming up with some value to put in the map in order to return a &mut V, which is a foot-gun. IndexAssign shouldn't require that.

[Jules-Bertholet]

HashMap would implement IndexMut such that fn index_mut would panic if the key is not found, but would override the default fn index_set to perform the insertion.

pub trait IndexMut<Idx: ?Sized>: Index<Idx> {
    fn index_mut(&mut self, index: Idx) -> &mut Self::Output;

    fn index_set(&mut self, index: Idx, value: Self::Output) {
        *self.index_mut(index) = value;
    }
}


impl<K, Q: ?Sized, V, S> IndexMut<&Q> for HashMap<K, V, S>
where
    K: Eq + Hash + Borrow<Q>,
    Q: Eq + Hash,
    S: BuildHasher,
{
    fn index_mut(&self, key: &Q) -> &mut V {
        self.get_mut(key).expect("no entry found for key")
    }

    fn index_set(&mut self, index: Idx, value: Self::Output) {
        self.insert(index, value);
    }
}

[RustyYato]

that doesn't work for HashMap because it would require implementing IndexMut which requires coming up with some value to put in the map in order to return a &mut V, which is a foot-gun. IndexAssign shouldn't require that.

That's not the problem with HashMap. We could just say that index_mut will panic on missing keys and index_assign will insert a new key. There is a different problem, we can't implement IndexMut for both Q: Hash + Eq, K: Borrow<Q> and for K: Hash + Eq without specialization. This is required because we can't insert a key of type Q into the hashmap.

    fn index_set(&mut self, index: Idx, value: Self::Output) {
        self.insert(index, value);
    }

Did you mean,

    fn index_set(&mut self, index: &Q, value: Self::Output) {
        self.insert(index, value);
    }

Which is illegal? &Q != K. (Which is why this is blocked on specialization, worse yet it requires the lattice rule of specialization which wasn't even part of the specialization RFC, just a future possibility).

Or you would need to implement IndexMut<K> for HashMap<K, V> which isn't nearly as useful for the index_mut case.

[Jules-Bertholet]

Did you mean,

    fn index_set(&mut self, index: &Q, value: Self::Output) {
        self.insert(index, value);
    }

Which is illegal? &Q != K.

I did mean that, and hadn't noticed the problem.

[RustyYato]

I guess another way we could handle this is to require Q: ToOwned<Owned = K>, and just convert it to the owned key on insertion.

This would still be a pretty significant limitation on index_mut, but it wouldn't introduce any major foot-guns.

Edit: although this would still force a clone to insert so maybe not

[tae-soo-kim]

1. DerefMove is not closely related to indexes. So why not split them in different topics?
2. DerefMove is simply the "owned" version of Deref (while DerefMut is the "mutable" version) that consumes the pointer.
3. Because DSTs can only be accessed behind a pointer, they can be prohibited from implementing DerefMove.
4. Then what is currently blocking the stabilization of DerefMove? Could we have an update in the original post so as not having to follow all the messages here?

[bjorn3]

What would the definition of DerefMove be. There are multiple options. It can't be trait DerefMove { fn deref_move(self) -> Self::Target; } as that doesn't work for unsized Self::Target.

[tae-soo-kim]

As I said DSTs may not implement it, because you can't play with DSTs without pointers anyway. Box::into_inner doesn't work for DSTs, and is that a problem?

[bjorn3]

You can dereference an unsized box on nightly if you pass the result as argument to a function. This is not something we can just give up on as the FnOnce impl for Box<dyn FnOnce()> depends on it.

Another thing is that you can partially move out of a box even on stable. This is incompatible with fn deref_move(self) -> Self:::Target too as that will move the entire content of the box all at once.

[tae-soo-kim]

You can dereference an unsized box on nightly if you pass the result as argument to a function. This is not something we can just give up on as the FnOnce impl for Box<dyn FnOnce()> depends on it.

Could you please post an example? I'm wondering what function can take a dereferenced unsized type as argument. Shouldn't they always stay behind pointers (and if so Deref or DerefMut might apply)?

Another thing is that you can partially move out of a box even on stable. This is incompatible with fn deref_move(self) -> Self:::Target too as that will move the entire content of the box all at once.

DerefMove means to consume the (entire) box, so yes you can't have anything in the box afterwards, not even a partial box, because the box itself is gone. If Box is such a special box that needs to have partial move, then DerefMove is not good for it. Maybe the compiler could be made more clever to differentiate let _ = *box from let _ = (*box).0? I'm not very inclined to this idea, but I think partial move behind box doesn't quality the blockade of implementing DerefMove.

[bjorn3]

Could you please post an example? I'm wondering what function can take a dereferenced unsized type as argument. Shouldn't they always stay behind pointers (and if so Deref or DerefMut might apply)?

fn accept_unsized_fnonce(a: dyn FnOnce()) { a(); } is an example. Rustc will use a pointer in the calling convention, but it is an owned value in the surface language, so you can move out of it like regular owned value. This is necessary for calling FnOnce for example as it moves the captured upvars of the closure. If you were to call accept_unsized_fnonce with *mybox as argument, rustc would take a pointer to the inner value of mybox and pass it to accept_unsized_fnonce and only after the call returns deallocate the box, but without dropping the inner value as that would have been dropped by accept_unsized_fnonce already.

[vigna]

IndexGet would be invaluable for all data structures with an implicit representation, and they're very important today in large data center: inverted indices, graph storage, etc., very often use succinct or compressed [immutable] representations, and there's no way to implement Index on them because there's no way to return a reference (as the data is represented implicitly). We are working on a library of succinct data structures and we had to define manually get methods. It would be really nice to have a standard "index and return a value" trait instead, both for ease of integration with other libraries and for ergonomics.

[vigna]

BTW, if there's any kind of requirement on the compiler to support these traits properly the 2024 edition would be the right occasion to think about it.

[Zoybean]

fn accept_unsized_fnonce(a: dyn FnOnce()) { a(); } is an example.

that doesn't compile currently on playground. but it seems like what you described would apply to the impl FnOnce for Box<FnOnce>

[tesaguri]

fn accept_unsized_fnonce(a: dyn FnOnce()) { a(); } is an example.

that doesn't compile currently on playground. but it seems like what you described would apply to the impl FnOnce for Box<FnOnce>

Yes, as bjorn3 said, that works on nightly, not on stable yet. It also requires the unstable feature #[feature(unsized_fn_params)], which is implicitly used by the FnOnce<_> impl for Box<dyn FnOnce<_>>.

The Unstable Book section for the unsized_locals feature even mentions that:

One of the objectives of this feature is to allow Box<dyn FnOnce>.