On May 15, 2014, at 9:54 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> On 16/05/14 12:48 AM, Tommi wrote:
>> On 2014-05-16, at 7:35, Steven Fackler <sfack...@gmail.com> wrote:
>>
>>> Type annotations are not there for the compiler; they're there for people
>>> reading the code. If I want to use some function I don't want to be forced
>>> to read the entire implementation to figure out what the lifetime of the
>>> return value is.
>>
>> Just to be sure... I take it you are in fact implying that "yes, it is
>> possible for the compiler to figure out those lifetimes without the
>> programmer explicitly specifying them in the function signature"?
>
> Lifetimes are based on subtyping, and AFAIK that presents huge problems
> for type inference. You would need to ask Niko how feasible it would be
> to infer it globally. I used to run into all sorts of problems with the
> *local* inference but it got a lot better.
I don't think global inference even is possible for this, because the lifetimes
affect borrowing. Example:
pub trait Foo {
fn foo(&self) -> &str;
}
This is a trait that defines a method `foo()` that returns a reference. I've
elided the lifetimes. Now tell me, if I'm calling this method through a generic
(or a trait object), what is the lifetime of the returned value? Is it the same
as `&self`, meaning does it need to borrow the receiver? Or is it 'static
(which won't borrow the receiver)?
-Kevin
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
