-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Hierarchic anonymous life-time #2949
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 5 commits
8c8324d
8a3bb00
3ff7ef8
4558622
bb9b711
5044d33
04a88c3
0260279
233839a
f6caad2
585fb1f
cf4f0c1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
@@ -0,0 +1,136 @@ | ||||||||||||||||||
- Feature Name: Hierarchic anonymous life-time | ||||||||||||||||||
- Start Date: 2020-06-24 | ||||||||||||||||||
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) | ||||||||||||||||||
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) | ||||||||||||||||||
|
||||||||||||||||||
# Summary | ||||||||||||||||||
|
||||||||||||||||||
New use of anonymous life-time '_ that implicitly added to current structure | ||||||||||||||||||
|
||||||||||||||||||
# Motivation | ||||||||||||||||||
|
||||||||||||||||||
Motivation is to simplify iterative development and improving refactoring of the code | ||||||||||||||||||
|
||||||||||||||||||
Sometimes during refactoring such code: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject { | ||||||||||||||||||
obj: SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct BigObject { | ||||||||||||||||||
composite_obj: CompositeObject, | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application { | ||||||||||||||||||
big_obj: BigObject, | ||||||||||||||||||
} | ||||||||||||||||||
redradist marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||
``` | ||||||||||||||||||
|
||||||||||||||||||
developer decides to make obj of SomeType as reference in CompositeObject type: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject<'a> { | ||||||||||||||||||
obj: &'a SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct BigObject<'a> { | ||||||||||||||||||
composite_obj: CompositeObject<'a>, | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application<'a> { | ||||||||||||||||||
big_obj: BigObject<'a>, | ||||||||||||||||||
} | ||||||||||||||||||
redradist marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||
``` | ||||||||||||||||||
Everywhere in composition hierarchy I need to write 'a ... most of the times it is just boilerplate code ... | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||||||||||||
|
||||||||||||||||||
What if instead of writing manually we will specify reference fields with anonymous life-time: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject { | ||||||||||||||||||
obj: &'_ SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct BigObject { | ||||||||||||||||||
composite_obj: CompositeObject, | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application { | ||||||||||||||||||
big_obj: BigObject, | ||||||||||||||||||
} | ||||||||||||||||||
redradist marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||
``` | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that you need some notation on each point of use to specify that a lifetime was elided. That is, But even this wouldn't be sufficient: this feature wants to abstract away the number of lifetime parameters too (we could have two fields with elided lifetimes). So maybe Now, you perhaps need some notation in the struct definitions too to specify that there are N elided lifetimes. For symmetry, With those additions, the feature seems less appealing. But without them, it's confusing. |
||||||||||||||||||
|
||||||||||||||||||
Code much simpler and more maintainable than fighting with named life-times in composite hierarchy | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
It is not true that it is more maintainable, I would say it is harder to maintain but being easier to refactor, being easy to refactor is one part, being maintainable but being implicit makes it harder to maintain. |
||||||||||||||||||
|
||||||||||||||||||
Compiler underhood will generate the following code: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject<'anon> { // 'anon is implicitly added life-time | ||||||||||||||||||
obj: &'anon SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct BigObject<'anon> { // 'anon is implicitly added life-time | ||||||||||||||||||
composite_obj: CompositeObject<'anon>, // 'anon is implicitly used here | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application<'anon> { // 'anon is implicitly added life-time | ||||||||||||||||||
big_obj: BigObject<'anon>, // 'anon is implicitly used here | ||||||||||||||||||
} | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the following code is generated, how will a reader knows that struct BigObject {
composite_obj: CompositeObject,
count: i32,
} have an implicit There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@pickfire Actually thinking ... what explicit life-time gives you ? You just need to know how to initialize There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To me it has been quite helpful to see explicit lifetimes because then I know that there is a lifetime being tracked inside the structure. In that way, it is a very helpful kind of documentation. One that is also always up-to-date, which is not a common feature of documentation in general. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@felix91gr You answer a question: "... it is a very helpful kind of documentation ...", it is mix of multiple stuffs in one ... it breakage of lot of pattern like Lets not mix life-time with good documentation ... from my point you should only know how to initialize Responsibility of proper handling life-time is responsibility of Bypassing life-time from "low-level" structures to "high-level" structures (logically) is violation of layers responsibilities Each abstract layer souls be responsible for its stuff There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Those patterns were created as heuristics for Object-Oriented Programming, not as tips for general design. In this case, having two responsibilities is good - it puts the information in exactly one place, instead of two. Keeping the documentation of what this lifetime is affecting becomes trivial once you have to keep it written, doesn't it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Take a look at examples above with syntax like this: struct CompositeObject& {
obj0: &SomeType, # Deduce life-time for this reference
obj1: &SomeType, # Deduce life-time for this reference
} or even just notification that in future structure will use references: struct CompositeObject& { // No references inside, but may will be in future
obj0: SomeType,
obj1: SomeType,
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe at this point the RFC is basically lifetime elision in type declarations with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There is on big difference There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It doesn't, you can use a single lifetime but many references. Having more than one lifetime in a type's definition is only useful for disambiguating them for the user, but you can't do that with & anyway. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Okay, will it be possible to use struct CompositeObject<'_> { // No references inside, but may will be in future
obj0: SomeType,
obj1: SomeType,
} |
||||||||||||||||||
``` | ||||||||||||||||||
|
||||||||||||||||||
Take a look at example with multiple anonymose life-times: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject { | ||||||||||||||||||
obj0: &'_ SomeType, | ||||||||||||||||||
obj1: &'_ SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
Comment on lines
+98
to
+101
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
Hidden lifetimes are deprecated, you also don't ever want There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @CryZe What if the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @redradist Why not? Both of them could depend on the same lifetime and life as long as each other. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@pickfire But what would be semantic of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's true even though it is uncommon. |
||||||||||||||||||
|
||||||||||||||||||
struct BigObject { | ||||||||||||||||||
composite_obj: CompositeObject, | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application { | ||||||||||||||||||
big_obj: BigObject, | ||||||||||||||||||
} | ||||||||||||||||||
``` | ||||||||||||||||||
code will be translated to: | ||||||||||||||||||
```rust | ||||||||||||||||||
struct CompositeObject<'anon0, 'anon1> { // 'anon0 and 'anon1 are implicitly added life-times | ||||||||||||||||||
obj0: &'anon0 SomeType, | ||||||||||||||||||
obj1: &'anon1 SomeType, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct BigObject<'anon0, 'anon1> { // 'anon is implicitly added life-time | ||||||||||||||||||
composite_obj: CompositeObject<'anon0, 'anon1>, // 'anon is implicitly used here | ||||||||||||||||||
count: i32, | ||||||||||||||||||
} | ||||||||||||||||||
|
||||||||||||||||||
struct Application<'anon0, 'anon1> { // 'anon is implicitly added life-time | ||||||||||||||||||
big_obj: BigObject<'anon0, 'anon1>, // 'anon is implicitly used here | ||||||||||||||||||
} | ||||||||||||||||||
``` | ||||||||||||||||||
|
||||||||||||||||||
On user side call should be like this: | ||||||||||||||||||
```rust | ||||||||||||||||||
fn make_app(config: &Config) -> Application; | ||||||||||||||||||
``` | ||||||||||||||||||
or | ||||||||||||||||||
```rust | ||||||||||||||||||
fn make_app(config: &Config) -> Application<'_>; | ||||||||||||||||||
``` | ||||||||||||||||||
|
||||||||||||||||||
# Drawbacks | ||||||||||||||||||
[drawbacks]: #drawbacks | ||||||||||||||||||
|
||||||||||||||||||
Not known at the current time | ||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are several drawbacks mentioned in the corresponding thread on IRLO and the comments on this PR. It would be helpful to list them here to get a better overview. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @pythoneer I will add ;) |
||||||||||||||||||
|
||||||||||||||||||
# Rationale and alternatives | ||||||||||||||||||
[rationale-and-alternatives]: #rationale-and-alternatives | ||||||||||||||||||
|
||||||||||||||||||
This design will help developers to iteravly play with library design, which should increase qualitty of the final library or application | ||||||||||||||||||
|
||||||||||||||||||
# Prior art | ||||||||||||||||||
[prior-art]: #prior-art | ||||||||||||||||||
|
||||||||||||||||||
There was disscutions on this topic in https://internals.rust-lang.org/t/simplification-reference-life-time/12224/20 |
Uh oh!
There was an error while loading. Please reload this page.