• Feature Name: unsized_locals
• Start Date: 2017-02-11
• RFC PR: rust-lang/rfcs#1909
• Rust Issue: rust-lang/rust#48055

Summary

Allow

Have repeat expressions

Provide some optimization guarantees

Motivation

There are 2 motivations for this RFC:

1. Passing unsized values, such as trait objects, to functions by value is often desired. Currently, this must be done through a Box<T> with an unnecessary allocation.
   割当

One particularly common example is passing closures that consume their environment

fn takes_closure(f: FnOnce()) { f(); }

But today you have to use a hack, such as taking

2. Allocating
   確保する
   a runtime-sized variable
   変数、ストレージ
   on the stack is important for good performance in some use-cases - see RFC #1808, which this is intended to supersede.

Detailed design

設計（する）

Unsized Rvalues - language

言語

Remove the rule that requires all locals and rvalues to have a sized type. Instead, require the following:

1. The following expressions
   式
   must always return a Sized type:
   1. Function calls,
      呼び出し
      method calls,
      呼び出し
      operator
      演算子
      expressions
      式
      • implementing
        実装する
        unsized return values for function calls
        呼び出し
        would require the called
        呼び出し
        function to do the alloca in our stack frame.
   2. ADT expressions
      式
      • see alternatives
   3. cast expressions
      式
      • this seems like an implementation
        実装
        simplicity
        単純さ、簡単さ
        thing. These can only be trivial casts.
2. The RHS of assignment
   代入
   expressions
   式
   must always have a Sized type.
   • Assigning
     代入する
     an unsized type is impossible because we don't know how much memory is available at the destination.
     行き先、目的地
     This applies
     適用する
     to ExprAssign assignments
     代入
     and not to StmtLet let-statements.

This also allows

For example:

struct StringData {
    len: usize,
    data: [u8],
}

fn foo(s1: Box<StringData>, s2: Box<StringData>, cond: bool) {
    // this creates a VLA copy of either `s1.1` or `s2.1` on
    // the stack.
    let mut s = if cond {
        s1.data
    } else {
        s2.data
    };
    drop(s1);
    drop(s2);
    foo(s);
}

fn example(f: for<'a> FnOnce(&'a X<'a>)) {
    let x = X::new();
    f(x); // aka FnOnce::call_once(f, (x,));
}

VLA expressions

式

Allow

extern "C" {
   fn random() -> usize;
}

fn foo(n: usize) {
    let x = [0u8; n]; // x: [u8]
    let x = [0u8; n + (random() % 100)]; // x: [u8]
    let x = [0u8; 42]; // x: [u8; 42], like today
    let x = [0u8; random() % 100]; //~ ERROR constant evaluation error
}

"captures a variable"

The last error message could have a user-helpful note, for example "extract

Unsized Rvalues - MIR

The way this is implemented

Unsized locals can never be reassigned within a scope. When first assigning

MIR construction

Guaranteed

保証する

Temporary

一時的な

Elision

MIR likes to create lots of temporaries

TODO: add description of problem & solution.

How We Teach This

Passing arguments

The "guaranteed

Drawbacks

In Unsafe code, it is very easy to create unintended temporaries,

unsafe fn poke(ptr: *mut [u8]) { /* .. */ }
unsafe fn foo(mut a: [u8]) {
    let ptr: *mut [u8] = &mut a;
    // here, `a` must be copied to a temporary, because
    // `poke(ptr)` might access the original.
    bar(a, poke(ptr));
}

If we make [u8] be Copy, that would be even easier, because even uses of poke(ptr); after the function call

And even if it is not as easy, it is possible to accidentally create temporaries

Unsized temporaries

Alternatives

The bikeshed

There are several alternative

1. The RFC choice, [t; φ] has type [T; φ] if φ captures no variables
   変数、ストレージ
   and type [T] if φ captures a variable.
   変数、ストレージ
   • pro: can be understood using "HIR"/resolution only.
   • pro: requires no additional
     追加の
     syntax.
     文法
   • con: might be confusing at first glance.
   • con: [t; foo()] requires the length to be extracted
     抽出する
     to a local.
2. The "permissive" choice: [t; φ] has type [T; φ] if φ is a constexpr, otherwise
   さもなければ
   [T]
   • pro: allows
     許可する、可能にする
     the most code
   • pro: requires no additional
     追加の
     syntax.
     文法
   • con: depends on what is exactly
     正確に
     a const expression.
     式
     This is a big issue because that is both non-local and might change between rustc versions.
3. Use the expected type - [t; φ] has type [T] if it is evaluated
   評価する（される）
   in a context
   文脈、背景
   that expects that type (for example [t; foo()]: [T]) and [T; _] otherwise.
   さもなければ
   • pro: in most cases, very human-visible.
   • pro: requires no additional
     追加の
     syntax.
     文法
   • con: relies on the notion of "expected type". While I think we do have to rely on that in the unsafe code semantics of &foo borrow expressions
     式
     (as in, whether a borrow is treated
     取り扱う
     as a "safe" or "unsafe" borrow - I'll write more details sometime), it might be better to not rely on expected types too much.
4. use an explicit
   明示的な
   syntax,
   文法
   for example [t; virtual φ].
   • bikeshed: exact syntax.
     文法
   • pro: very explicit
     明示的な
     and visible.
   • con: more syntax.
     文法
5. use an intrinsic, std::intrinsics::repeat(t, n) or something.
   • pro: theoretically minimizes changes to the language.
     言語
   • con: requires returning unsized values from intrinsics.
   • con: unergonomic to use.

Unsized ADT Expressions

式

Allowing unsized ADT expressions

let len_ = s.len();
let p = Box::new(PascalString {
    length: len_,
    data: *s
});

However, without some way to guarantee

Copy Slices

One somewhat-orthogonal proposal that came up was to make Clone (and therefore Copy) not depend on Sized, and to make [u8] be Copy, by moving the Self: Sized bound

pub trait Clone {
    fn clone(&self) -> Self where Self: Sized;
    fn clone_from(&mut self, source: &Self) where Self: Sized {
        // ...
    }
}

That would be a backwards-compatability-breaking change, because today T: Clone + ?Sized (or of course Self: Clone in a trait context,

Unresolved questions

How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid

How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries.

Accumulative allocas (aka 'fn borrows) are beyond the scope of this RFC.

See alternatives.