On 13-02-05 10:50 AM, Niko Matsakis wrote: > We are reaching a degree of consensus on the new lifetime syntax.
Yeah, I think at this point I'm willing to (again) bust out the BDFL hat and say that, absent _incoherence or ambiguity_ in this proposal, it's no longer time for fiddling with the sigils and brackets. We have to move ahead on this. If it works, let's go with it. If something terrible is lurking in the usability, we'll discover it in the future. > # Lifetime names and borrowed pointers All of this section, agree 100%. > # Lifetime parameters and fn/struct declarations Likewise, A-ok here. > # Lifetime parameters and impls > > ... > > This is *slightly* different than today. This is because, today, > `&self` is equivalent to a self type of `&'b Iterator<'b, T>` rather > than using a fresh lifetime (like `&'a Iterator<'a, T>`). The current > system causes various issues in real-life examples, including this > specific iterator example. I do not entirely understand what the failure mode is. Are you saying that today, an omitted lifetime parameter in an impl method signature gets its default provided from the underlying type's lifetime parameter, whereas in the new regime it will get a fresh parameter provided? If so, I don't know the exact way it goes wrong (or really see it in the example here), but it works better, I trust you know why, that's fine. If you mean something else, I'd like a little more illumination. I _almost_ understand what's going on here :) > # Multiple lifetime parameters > ... > You can write `Foo` or `Foo<'lt1, 'lt2>` but not `Foo<'lt1>`. Yes. All or none. > # Labeling blocks and expressions Compatible and future-concern, defer. (Thanks for the tireless care to get this all worked out.) -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
