I want to write a program that will write a file in 2 steps. It is likely that the file may not exist before the program is run. The filename is fixed.
The problem is that OpenOptions.new().write()
can fail. In that case, I want to call a custom function trycreate()
. The idea is to create the file instead of opening it and return a handle. Since the filename is fixed, trycreate()
has no arguments and I cannot set a lifetime of the returned value.
How can I resolve this problem?
use std::io::Write; use std::fs::OpenOptions; use std::path::Path; fn trycreate() -> &OpenOptions { let f = OpenOptions::new().write(true).open("foo.txt"); let mut f = match f { Ok(file) => file, Err(_) => panic!("ERR"), }; f } fn main() { { let f = OpenOptions::new().write(true).open(b"foo.txt"); let mut f = match f { Ok(file) => file, Err(_) => trycreate("foo.txt"), }; let buf = b"test1\n"; let _ret = f.write(buf).unwrap(); } println!("50%"); { let f = OpenOptions::new().append(true).open("foo.txt"); let mut f = match f { Ok(file) => file, Err(_) => panic!("append"), }; let buf = b"test2\n"; let _ret = f.write(buf).unwrap(); } println!("Ok"); }
Functions can be declared to return a reference type. There are two reasons to make such a declaration: The information being returned is a large enough object that returning a reference is more efficient than returning a copy. The type of the function must be an l-value.
@Anisha Kaul: Yes.
It is dangerous to have a dangling pointer like that as pointers or references to local variables are not allowed to escape the function where local variables live; hence, the compiler throws an error.
The return keyword can be used to return a value inside a function's body. When this keyword isn't used, the last expression is implicitly considered to be the return value. If a function returns a value, its return type is specified in the signature using -> after the parentheses () .
TL;DR: No, you cannot return a reference to a variable that is owned by a function. This applies if you created the variable or if you took ownership of the variable as a function argument.
Instead of trying to return a reference, return an owned object. String
instead of &str
, Vec<T>
instead of &[T]
, T
instead of &T
, etc.
If you took ownership of the variable via an argument, try taking a (mutable) reference instead and then returning a reference of the same lifetime.
In rare cases, you can use unsafe code to return the owned value and a reference to it. This has a number of delicate requirements you must uphold to ensure you don't cause undefined behavior or memory unsafety.
See also:
fjh is absolutely correct, but I want to comment a bit more deeply and touch on some of the other errors with your code.
Let's start with a smaller example of returning a reference and look at the errors:
fn try_create<'a>() -> &'a String { &String::new() }
Rust 2015
error[E0597]: borrowed value does not live long enough --> src/lib.rs:2:6 | 2 | &String::new() | ^^^^^^^^^^^^^ temporary value does not live long enough 3 | } | - temporary value only lives until here | note: borrowed value must be valid for the lifetime 'a as defined on the function body at 1:15... --> src/lib.rs:1:15 | 1 | fn try_create<'a>() -> &'a String { | ^^
Rust 2018
error[E0515]: cannot return reference to temporary value --> src/lib.rs:2:5 | 2 | &String::new() | ^------------- | || | |temporary value created here | returns a reference to data owned by the current function
Is there any way to return a reference from a function without arguments?
Technically "yes", but for what you want, "no".
A reference points to an existing piece of memory. In a function with no arguments, the only things that could be referenced are global constants (which have the lifetime &'static
) and local variables. I'll ignore globals for now.
In a language like C or C++, you could actually take a reference to a local variable and return it. However, as soon as the function returns, there's no guarantee that the memory that you are referencing continues to be what you thought it was. It might stay what you expect for a while, but eventually the memory will get reused for something else. As soon as your code looks at the memory and tries to interpret a username as the amount of money left in the user's bank account, problems will arise!
This is what Rust's lifetimes prevent - you aren't allowed to use a reference beyond how long the referred-to value is valid at its current memory location.
See also:
Look at the documentation for OpenOptions::open
:
fn open<P: AsRef<Path>>(&self, path: P) -> Result<File>
It returns a Result<File>
, so I don't know how you'd expect to return an OpenOptions
or a reference to one. Your function would work if you rewrote it as:
fn trycreate() -> File { OpenOptions::new() .write(true) .open("foo.txt") .expect("Couldn't open") }
This uses Result::expect
to panic with a useful error message. Of course, panicking in the guts of your program isn't super useful, so it's recommended to propagate your errors back out:
fn trycreate() -> io::Result<File> { OpenOptions::new().write(true).open("foo.txt") }
Option
and Result
have lots of nice methods to deal with chained error logic. Here, you can use or_else
:
let f = OpenOptions::new().write(true).open("foo.txt"); let mut f = f.or_else(|_| trycreate()).expect("failed at creating");
I'd also return the Result
from main
. All together, including fjh's suggestions:
use std::{ fs::OpenOptions, io::{self, Write}, }; fn main() -> io::Result<()> { let mut f = OpenOptions::new() .create(true) .write(true) .append(true) .open("foo.txt")?; f.write_all(b"test1\n")?; f.write_all(b"test2\n")?; Ok(()) }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With