On 12/11/23 18:35, Boqun Feng wrote:
> On Mon, Dec 11, 2023 at 03:34:29PM +0000, Alice Ryhl wrote:
>> Boqun Feng <boqun.feng@xxxxxxxxx> writes:
>>> On Wed, Dec 06, 2023 at 11:59:47AM +0000, Alice Ryhl wrote:
>>> [...]
>>>> @@ -151,6 +152,21 @@ pub fn as_ptr(&self) -> *mut bindings::file {
>>>> self.0.get()
>>>> }
>>>>
>>>> + /// Returns the credentials of the task that originally opened the file.
>>>> + pub fn cred(&self) -> &Credential {
>>>
>>> I wonder whether it would be helpful if we use explicit lifetime here:
>>>
>>> pub fn cred<'file>(&'file self) -> &'file Credential
>>>
>>> It might be easier for people to get. For example, the lifetime of the
>>> returned Credential reference is constrainted by 'file, the lifetime of
>>> the file reference.
>>>
>>> But yes, maybe need to hear others' feedback first.
>>>
>>> Regards,
>>> Boqun
>>
>> That would trigger a compiler warning because the lifetime is
>> unnecessary.
>>
>
> We can disable that warning if people need the information. Code is
> mostly for reading, less often for compilation and changes.
>
>> The safety comment explains what the signature means. I think that
>> should be enough.
>>
>
> For someone who has a good understanding of Rust lifetime (and the
> elision), yes. But I'm wondering whether all the people feel the same
> way.
So in this example, I think it should be straight forward what happens
to the lifetimes, since there is only one to begin with.
If we want to do this, I think we should have some rules around it.
A general piece of advice I can offer is this:
- when there are no lifetimes in the return type of a function, then you
probably do not care about the lifetimes (they will all be distinct
and there are no relationships between them).
- when there is a single input and a single output lifetime, then
they are the same.
- the other cases are not so simple, but most of the time they will
require explicit annotations.
I left out some details, you can read more at [1]. Most cases where it
is not obvious which lifetime relations exist are already rejected by
the compiler. The only exception is if there is a `&self` or `&mut self`
parameter, then that one has precedence. So we could also explicitly
annotate those. Since they are also rare, I think this would be fine.
[1]: https://doc.rust-lang.org/nomicon/lifetime-elision.html
--
Cheers,
Benno
