Unsized Rvalues

Author: arielb1

text/0000-unsized-rvalues.md

@@ -0,0 +1,167 @@
+- Feature Name: unsized_locals
+- Start Date: 2017-02-11
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+Allow for local variables, function arguments, and some expressions to have an unsized type, and implement it by storing the temporaries in variably-sized allocas.
+
+Have repeat expressions with a length that captures local variables be such an expression, returning an `[T]` slice.
+
+Provide some optimization guarantees that unnecessary temporaries will not create unnecessary allocas.
+
+# Motivation
+[motivation]: #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 without using monomorphization. One would like for this code to work:
+
+```Rust
+fn takes_closure(f: FnOnce()) { f(); }
+```
+
+But today you have to use a hack, such as taking a `Box<FnBox<()>>`.
+
+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
+[design]: #detailed-design
+
+## Unsized Rvalues - language
+
+Remove the rule that requires all locals and rvalues to have a sized type. Instead, require the following:
+a) The following expressions must always return a Sized type:
+    a1) 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.
+    a2) ADT expressions
+        - see alternatives
+    a3) cast expressions
+        - this seems like an implementation simplicity thing. These can only be trivial casts.
+b) 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 passing unsized values to functions, with the ABI being as if a `&move` pointer was passed (a `(by-move-data, extra)` pair). This also means that methods taking `self` by value are object-safe, though vtable shims are sometimes needed to translate the ABI (as the callee-side intentionally does not pass `extra` to the fn in the vtable, no vtable shim is needed if the vtable function already takes its argument indirectly).
+
+For example:
+
+```Rust
+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.1
+    } else {
+        s2.1
+    };
+    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 repeat expressions to capture variables from their surrounding environment. If a repeat expression captures such a variable, it has type `[T]` with the length being evaluated at run-time. If the repeat expression does not capture any variable, the length is evaluated at compile-time. For example:
+```Rust
+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" - as in RFC #1558 - is used as the condition for making the return be `[T]` because it is simple, easy to understand, and  introduces no type-checking complications.
+
+## Unsized Rvalues - MIR
+
+The way this is implemented in MIR is that operands, rvalues, and temporaries are allowed to be unsized. An unsized operand is always "by-ref". Unsized rvalues are either a `Use` or a `Repeat` and both can be translated easily.
+
+Unsized locals can never be reassigned within a scope. When first assigning to an unsized local, a stack allocation is made with the correct size.
+
+MIR construction remains unchanged. 
+
+## Guaranteed Temporary Elision
+
+MIR likes to create lots of temporaries for OOE reason. We should optimize them out in a guaranteed way in these cases (FIXME: extend these guarantees to locals aka NRVO?).
+
+TODO: add description of problem & solution.
+    
+# How We Teach This
+[teach]: #how-we-teach-this
+
+Passing arguments to functions by value should not be too complicated to teach. I would like VLAs to be mentioned in the book.
+
+The "guaranteed temporary elimination" rules require more work to teach. It might be better to come up with new rules entirely.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+In Unsafe code, it is very easy to create unintended temporaries, such as in:
+```Rust
+unsafe fnf 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 could potentially access the supposedly-valid data behind `a`.
+
+And even if it is not as easy, it is possible to accidentally create temporaries in safe code.
+
+Unsized temporaries are dangerous - they can easily cause aborts through stack overflow.
+
+# Alternatives
+[alternatives]: #alternatives
+
+Allowing unsized ADT expressions would make unsized structs constructible without using unsafe code, as in:
+```Rust
+let len_ = s.len();
+let p = Box::new(PascalString {
+    length: len_,
+    data: *s
+});
+```
+
+However, without some way to guarantee that this can be done without allocas, that might be a large footgun.
+
+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 from the trait to the methods, i.e. using the following declaration:
+```Rust
+pub trait Clone {
+    fn clone(&self) -> Self where Self: Sized;
+    fn clone_from(&mut self, source: &Self) where Self: Sized {
+        // ...
+    }
+}
+```
+
+# Unresolved questions
+[unresolved]: #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 these stack overflows. Do we want it in Clippy? rustc?
+
+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.
+
+See alternatives.