Rust's language ergonomics initiative
A challenge I&#x27;ve had with Rust lately is factoring initialization code into separate functions. Because of stack-based allocation it has to stay in the main function. For example:<p><pre><code>    pub fn do_many(iter: &amp;mut Iterator&lt;Item=String&gt;) {
      let mut job_id = None;
      let job_id_env = env::var(&quot;MYAPP_JOB_ID&quot;);
      let mut log = if let Ok(val) = job_id_env {
        write_pid_file(&amp;val);
        job_id = Some(val.clone());
        let home = env::var(&quot;HOME&quot;).expect(&quot;HOME must be set&quot;);
        let path = format!(&quot;{}&#x2F;log&#x2F;myapp-{}.log&quot;, home, val);
        let path = Path::new(&amp;path);
        match File::create(&amp;path) {
          Ok(mut f) =&gt; Box::new(f) as Box&lt;Write&gt;,
          Err(e) =&gt; {
            if format!(&quot;{}&quot;, e) == &quot;No such file or directory (os error 2)&quot; {
              Box::new(io::stdout()) as Box&lt;Write&gt; &#x2F;&#x2F; oh well
            } else {
              panic!(&quot;Can&#x27;t open log file: {}&quot;, e);
            }
          },
        }
      } else {
        Box::new(io::stdout()) as Box&lt;Write&gt;
      };

      &#x2F;&#x2F; Commit the tx if we get these signals:
      let signal = chan_signal::notify(&amp;[Signal::INT, Signal::TERM]);

      let negotiator = OpenSsl::new().unwrap();
      let url = env::var(&quot;MYAPP_DATABASE&quot;).unwrap_or(&quot;postgres:&#x2F;&#x2F;myapp_test:secret@localhost:5432&#x2F;myapp_test&quot;.to_owned());
      let tls = if url.contains(&quot;@localhost&quot;) { TlsMode::None }
                else { TlsMode::Require(&amp;negotiator) };
      let conn = Connection::connect(url, tls).expect(&quot;Can&#x27;t connect to Postgres&quot;);
      let db = make_db_connection(&amp;conn); &#x2F;&#x2F; defines a bunch of prepared statements
      
      &#x2F;&#x2F; now we can do stuff . . . 

    }
</code></pre>
I would really like to have just this:<p><pre><code>    let log = open_log();
    let db = prepare_db();
</code></pre>
But those don&#x27;t work, because all the temporary values are going to fall off the stack when the helper functions return. I wish rust were smart enough to make the functions put the values directly in the <i>caller</i>&#x27;s stack frame. Alternately, I wish rust would let me say that all those temporary values should live as long as the returned thing (log and db), so it can keep them around even if I don&#x27;t have variables for them.<p>I thought maybe macros would help here, since there is no new stack frame, but they still introduce a new scope that limits the lifetime of the temporary variables.<p>Even worse, if I want to write tests for functions that use the log and db, I need to repeat all that code again and again.<p>I think the answer is to use Box here? I haven&#x27;t worked that out yet, but it definitely feels harder than it should. And even if I can make it work, I&#x27;m a little sad that I have to give up stack-based allocation.<p>I&#x27;ve also read that the answer might be OwningRef (<a href="https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;owning_ref" rel="nofollow">https:&#x2F;&#x2F;crates.io&#x2F;crates&#x2F;owning_ref</a>), but I&#x27;m not sure yet. I wish the Rust book had a section about it. It seems like Cow and Rc might also help me---I don&#x27;t think so, but I&#x27;m not positive yet. Covering these allocation-related crates in a systematic way would be nice.<p>Anyway, I&#x27;m just a Rust newbie, but it sounds like the ergonomics effort is (partly) for newbies like me, so I&#x27;m trying to express my struggles in terms of a pattern that the Rust team could optimize for. It seems like something that people would hit quite often. I&#x27;m sure there is an answer to what I&#x27;m trying to do, so my point is that maybe it should be easier to find, or at least better documented.