These are chat archives for rust-lang/rust

25th
Feb 2017
Peter Atashian
@retep998
Feb 25 2017 04:32
@mtanski At the moment Rust does not support LTO between it and other languages
Aravindh Sridharan
@hardvain
Feb 25 2017 10:03
Why do we need to add a , after generic type bounds using where?
For example, in the following code
fn add<A, B>(a: A, b: B) -> Box<Future<Item=i32, Error=A::Error>>
    where A: Future<Item=i32>,
          B: Future<Item=i32, Error=A::Error>, {
    Box::new(a.join(b).map(|(a, b)| a + b))
}
Why is there a , after Error=A::Error>
Just noticed that it is optional
Peter Atashian
@retep998
Feb 25 2017 10:06
@hardvain Anywhere you split things with commas, you can have an optional trailing comma,
Aravindh Sridharan
@hardvain
Feb 25 2017 10:07
@retep998 Thanks for the information. :thumbsup:
Aravindh Sridharan
@hardvain
Feb 25 2017 10:28
The following code gives me the error: “Missing lifetime specifier. This funciton’s return type contains a borrowed value, but there is no value to be borrwed from”.
fn get_name() -> &str {
    "aravindh”
}
How does rust decide &str is a borrowed value?
If i am right, &str is the type of string literals
what if I want to have a method which just returns a string literal?
Joonas Koivunen
@koivunej
Feb 25 2017 10:30
@hardvain the lifetime specifier for "string literals" is 'static as the literal gets compiled into the binary, it lives for the duration of the program (is 'static)
Aravindh Sridharan
@hardvain
Feb 25 2017 10:31
Oh
Actually adding static works

fn get_name() -> &'static str {
    "aravindh"
}
But cant the compiler figure it out here since all i am doing is just returning a string literal
and cant it infer the `static lifetime ?
Aleksey Kladov
@matklad
Feb 25 2017 10:33
Return types of functions are not inferred. This is an explicit design decision to make it possible to typecheck Rust looking only on the function prototypes.
However, there's a somewhat similar feature of "lifetime elision" which sometimes allows one to omit the explicit lifetime, but it still works on the signature only, and does not look at the body.
For example, if you write fn foo(x: &T) -> &str rust will desugar this to fn foo<'a>(x: &'a T) -> &'a str. That is, the compile would guess that the output lifetime is equal to the single input lifetime.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:39
@matklad Thanks for the information. I am looking at https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html to read about lifetime elision.
Here
In the example
fn debug(lvl: uint, s: &str);                           // elided
fn debug<'a>(lvl: uint, s: &'a str);                    // expanded
The lvl has not lifetime after desugaring because it is moved and not borrowed. am i right?
Aleksey Kladov
@matklad
Feb 25 2017 10:39
Yes
Aravindh Sridharan
@hardvain
Feb 25 2017 10:40
Well the term elision seems difficult. But I guess it can be said simply as lifetime inference. isnt it
When I first stumbled upon the term lifetime elision in rust, i thought it was some advanced concept and decided to read it later :P guess its not that difficult
Aleksey Kladov
@matklad
Feb 25 2017 10:41
Well, yes and now. Yes, because the end result is the same: you can omit lifetimes in certain places.
No, because unlike the true inference, ellison can give you incorrect results some times.
For example, for method like fn foo(&self, x: &T) -> &str, the unelided form is fn foo<'a, 'b>(&'a self, x: &'b T) -> &'a str.
That is, by default compiler thinks that self is more important than other parameters, and binds the lifetime of the output to self.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:43
I guess thats because of this: So to summarize, in rust, we cant have function which dont take any input values and return some value and without mentioning lifetimes. ?
Ya. got it
sorry
wrongly pasted above
i guess it because of the following rule: If there are multiple input lifetime positions, but one of them is &self or &mut self, the lifetime of self is assigned to all elided output lifetimes.
Aleksey Kladov
@matklad
Feb 25 2017 10:44
but if you function looks like fn foo(&self, x: &T) -> &str { x.str() }, you actually want fn foo<'a, 'b>(&'a self, x: &'b T) -> &'b str.
THat is, elision, unlike inference, can give you wrong results.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:44
ya got it.
So to summarize, in rust, we cant have function which dont take any input values and return some value and without mentioning lifetimes ? This is because rust wont have any lifetime to assign to the return value because it cant infer any lifetime from the location of function invocation.
Aleksey Kladov
@matklad
Feb 25 2017 10:45
Yes, that's true currently.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:45
Thanks for your patient answers. Also pardon me for asking a lot of questions.
I guess I will be asking more questions as I am liking rust a lot these days and want to invest significant time in learning it
Aleksey Kladov
@matklad
Feb 25 2017 10:46
I can imagine the extension of the language though, where the output lifetimes unelide to 'static if there are no input lifetimes at all.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:47
Well ‘static can be problematic in case of non string literals isnt it. What if we return a baoxed value and it is assigned a static lifetime
Aleksey Kladov
@matklad
Feb 25 2017 10:47
For example this was recently added to static declarations: you can write static S: &str = "hello"; instead of static S: &'static str = "hello";
Aravindh Sridharan
@hardvain
Feb 25 2017 10:48
Instead, for a function without input and one output value, can we assign some lifetime based on the usage of the function invocation scope?
for example
Aleksey Kladov
@matklad
Feb 25 2017 10:48

What if we return a baoxed value and it is assigned a static lifetime

If we return something like Box<T>, we usually don't need a lifetime at all because box is an owned type.

Aravindh Sridharan
@hardvain
Feb 25 2017 10:48
ummm. Box may not be the right example
Aleksey Kladov
@matklad
Feb 25 2017 10:49
It would be hard to come up with example here: the only lifetime you can get our of thin air is 'static.
Aravindh Sridharan
@hardvain
Feb 25 2017 10:49
Anyhow, i will spend more time learning about this, compile my questions and ask here. Thanks again for the answers