Thinking of this again, it seems possible to avoid naming lifetimes if
we allow an optional parameter name when specifying types. The example I
gave before would become (with the current slash syntax):
struct Foo { f: int }
// We refer to v's lifetime with &v/...
fn takes_foo(v : Foo) -> &v/int {
&v.f
}
/////////////////////////////
// We give the name `toto` to the parameter of the function `f`.
// This name is only used to refer to this value's lifetime, never
to the value itself.
////////////////////////////
fn foobar(v: &Foo, f: fn(toto: &Foo) -> &toto/int) -> &toto/int{
f(v)
}
My feeling is that it would make the simple case more intuitive while
keeping the difficult case as difficult as before.
Does it make sense?
Samuel
On 02/05/2013 01:08 PM, Samuel de Framond wrote:
>
> On 02/05/2013 04:49 AM, Chris Peterson wrote:
>> After reading the recent discussions about lifetime notation, I was
>> wondering why lifetimes need their own names. Lifetimes refer to
>> variables that already have names. For example, given this fn from
>> the borrowed pointers tutorial:
> This is not always true. Consider a function that takes a function as
> parameter:
>
> struct Foo { f: int }
>
> fn takes_foo(v : </Foo) -> </int {
> &v.f
> }
>
> fn foobar(v: </Foo, f: fn(</Foo) -> </int) -> </int{
> f(v)
> }
>
> fn main() {
> let a = Foo {f: 1};
> let f = foobar(&a, takes_foo);
> io::println(fmt!("%?", f));
> }
>
--
Samuel de Framond
P: +86 135 8556 8964
M: [email protected]
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
