Why does Rust use the convention of single-letter lifetimes? [on hold]
up vote
1
down vote
favorite
Do lifetimes usually have single letters because their semantic purpose is difficult to describe in a word? Or purely to avoid verbosity?
Since I'm familiar with generics in other languages, I'm perfectly happy with using T as a convention to mean "the generic Type", I guess because the purpose of T is usually clear. For example Vec<T> to me reads clearly as "a Vec of T".
However, perhaps it's just because I'm new to the language, but I find 'a unclear, a bit like using single letter variable names everywhere without commenting. Some lifetime... but what? Why??
While experimenting with writing a little parser, I realised that my Parser<'a> could be written as Parser<'source>, since I passed a reference to the source string that I was parsing, which made my code feel a lot clearer, albeit more verbose.
Are there reasons why this isn't more common? Is it usually hard or impossible to boil down lifetimes to relate to a particular piece of data?
rust lifetime
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
put on hold as primarily opinion-based by hellow, Stargateur, jww, Sven Marnach, ewolden Nov 8 at 8:57
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
|
show 6 more comments
up vote
1
down vote
favorite
Do lifetimes usually have single letters because their semantic purpose is difficult to describe in a word? Or purely to avoid verbosity?
Since I'm familiar with generics in other languages, I'm perfectly happy with using T as a convention to mean "the generic Type", I guess because the purpose of T is usually clear. For example Vec<T> to me reads clearly as "a Vec of T".
However, perhaps it's just because I'm new to the language, but I find 'a unclear, a bit like using single letter variable names everywhere without commenting. Some lifetime... but what? Why??
While experimenting with writing a little parser, I realised that my Parser<'a> could be written as Parser<'source>, since I passed a reference to the source string that I was parsing, which made my code feel a lot clearer, albeit more verbose.
Are there reasons why this isn't more common? Is it usually hard or impossible to boil down lifetimes to relate to a particular piece of data?
rust lifetime
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
put on hold as primarily opinion-based by hellow, Stargateur, jww, Sven Marnach, ewolden Nov 8 at 8:57
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
1
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with'sourceis perfcetly legit und I would rather prefer that over'a.
– hellow
Nov 8 at 8:40
4
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reasonTis so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).
– DK.
Nov 8 at 8:40
1
When it's make sense, yes, please use a full word ! Serde use'defor dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple,fn(&self) -> &T, you would putfn<'source>(&'source self) -> &'source T?
– Stargateur
Nov 8 at 8:40
2
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,'awould just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so'ait is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.
– DK.
Nov 8 at 8:54
|
show 6 more comments
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Do lifetimes usually have single letters because their semantic purpose is difficult to describe in a word? Or purely to avoid verbosity?
Since I'm familiar with generics in other languages, I'm perfectly happy with using T as a convention to mean "the generic Type", I guess because the purpose of T is usually clear. For example Vec<T> to me reads clearly as "a Vec of T".
However, perhaps it's just because I'm new to the language, but I find 'a unclear, a bit like using single letter variable names everywhere without commenting. Some lifetime... but what? Why??
While experimenting with writing a little parser, I realised that my Parser<'a> could be written as Parser<'source>, since I passed a reference to the source string that I was parsing, which made my code feel a lot clearer, albeit more verbose.
Are there reasons why this isn't more common? Is it usually hard or impossible to boil down lifetimes to relate to a particular piece of data?
rust lifetime
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
Do lifetimes usually have single letters because their semantic purpose is difficult to describe in a word? Or purely to avoid verbosity?
Since I'm familiar with generics in other languages, I'm perfectly happy with using T as a convention to mean "the generic Type", I guess because the purpose of T is usually clear. For example Vec<T> to me reads clearly as "a Vec of T".
However, perhaps it's just because I'm new to the language, but I find 'a unclear, a bit like using single letter variable names everywhere without commenting. Some lifetime... but what? Why??
While experimenting with writing a little parser, I realised that my Parser<'a> could be written as Parser<'source>, since I passed a reference to the source string that I was parsing, which made my code feel a lot clearer, albeit more verbose.
Are there reasons why this isn't more common? Is it usually hard or impossible to boil down lifetimes to relate to a particular piece of data?
rust lifetime
rust lifetime
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
asked Nov 8 at 8:32
Joseph Humfrey
2,07811524
2,07811524
put on hold as primarily opinion-based by hellow, Stargateur, jww, Sven Marnach, ewolden Nov 8 at 8:57
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
put on hold as primarily opinion-based by hellow, Stargateur, jww, Sven Marnach, ewolden Nov 8 at 8:57
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
1
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with'sourceis perfcetly legit und I would rather prefer that over'a.
– hellow
Nov 8 at 8:40
4
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reasonTis so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).
– DK.
Nov 8 at 8:40
1
When it's make sense, yes, please use a full word ! Serde use'defor dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple,fn(&self) -> &T, you would putfn<'source>(&'source self) -> &'source T?
– Stargateur
Nov 8 at 8:40
2
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,'awould just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so'ait is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.
– DK.
Nov 8 at 8:54
|
show 6 more comments
1
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
1
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with'sourceis perfcetly legit und I would rather prefer that over'a.
– hellow
Nov 8 at 8:40
4
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reasonTis so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).
– DK.
Nov 8 at 8:40
1
When it's make sense, yes, please use a full word ! Serde use'defor dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple,fn(&self) -> &T, you would putfn<'source>(&'source self) -> &'source T?
– Stargateur
Nov 8 at 8:40
2
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,'awould just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so'ait is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.
– DK.
Nov 8 at 8:54
1
1
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
1
1
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with
'source is perfcetly legit und I would rather prefer that over 'a.– hellow
Nov 8 at 8:40
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with
'source is perfcetly legit und I would rather prefer that over 'a.– hellow
Nov 8 at 8:40
4
4
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reason
T is so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).– DK.
Nov 8 at 8:40
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reason
T is so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).– DK.
Nov 8 at 8:40
1
1
When it's make sense, yes, please use a full word ! Serde use
'de for dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple, fn(&self) -> &T, you would put fn<'source>(&'source self) -> &'source T ?– Stargateur
Nov 8 at 8:40
When it's make sense, yes, please use a full word ! Serde use
'de for dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple, fn(&self) -> &T, you would put fn<'source>(&'source self) -> &'source T ?– Stargateur
Nov 8 at 8:40
2
2
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,
'a would just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so 'a it is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.– DK.
Nov 8 at 8:54
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,
'a would just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so 'a it is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.– DK.
Nov 8 at 8:54
|
show 6 more comments
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
1
Note that this convention is not universal. Regularly, I see (or write) some code with a full world as lifetime identifier.
– Boiethios
Nov 8 at 8:33
1
Rust doesn't enforce the usage of single letter lifetimes. You can do whatever you want. Your example with
'sourceis perfcetly legit und I would rather prefer that over'a.– hellow
Nov 8 at 8:40
4
Not sure how long this will survive on SO since it's a pretty subjective question. Answer is probably: for the same reason
Tis so widely used. It's usually either obvious what it's for from context (tying a parameter to a return type), or doesn't really matter (the specifics don't matter, but I have to define some lifetime for these struct fields).– DK.
Nov 8 at 8:40
1
When it's make sense, yes, please use a full word ! Serde use
'defor dezerializer life time for exemple. But you generally don't need more than one lifetime (even no one with new rust feature that auto put it for you in a lot of usecase) and generally there is no need to add context to a lifetime so people use single letter. For exemple,fn(&self) -> &T, you would putfn<'source>(&'source self) -> &'source T?– Stargateur
Nov 8 at 8:40
2
@JosephHumfrey Often, no. I mean, if you have a lifetime in a structure, it has to outlive the structure. There's no way for it to not outlive it. If you've got a bunch of references in a structure,
'awould just be "the intersection of the lifetimes of the storage locations the following six references were derived from" which doesn't have a convenient, short name... so'ait is because no one really cares at that point. It's just "here is some stuff borrowed from elsewhere." I usually only bother naming lifetimes when there's more than one and the distinction does matter.– DK.
Nov 8 at 8:54