2017-10-01 8 views
6

RFC 1623, stabilisé à Rust 1.17.0, fait en sorte que nous ne devons pas spécifier explicitement la durée de vie 'static dans un static ou const:Quand est-il utile qu'une constante associée utilise une durée de vie autre que 'static'?

const MY_DEFAULT_NAME: &str = "Anna"; 
//     ^Look, ma! No 'static! 

RFC 195 définies constantes associées, qui ont été stabilisées à Rust 1.20.0:

struct A; 

impl A { 
    const B: i32 = 42; 
} 

Lorsque vous essayez de combiner ces deux, est soulevé une erreur:

struct A; 

impl A { 
    const MY_DEFAULT_NAME: &str = "Anna"; 
} 
error[E0106]: missing lifetime specifier 
--> src/main.rs:4:28 
    | 
4 |  const MY_DEFAULT_NAME: &str = "Anna"; 
    |       ^expected lifetime parameter 

Le related GitHub issue #38831 a a comment:

Nous avons décidé parce que, dans ce cas, il pourrait y avoir d'autres vies vous voulez. Par exemple:

trait Foo<'a> { 
    const T: &'a str; 
} 

qui a dit, revisitant cette explication, il se sentir un peu faible, puisque la valeur d'une constante associée devrait toujours être tous composés des données statiques. Donc, il semble que 'static est un très bon défaut si vous ne dites pas le contraire .

Qu'est-ce qu'un exemple de constante associée avec une durée de vie non 'static? Quel avantage apporte une durée de vie non-'static?

Répondre

4

On pourrait considérer une constante qui est fonction:

trait Foo<'a> { 
    const BAR: fn(&Self) -> &'a str; 
} 

struct MyFoo<'a> { 
    x: &'a str, 
} 

impl<'a> Foo<'a> for MyFoo<'a> { 
    const BAR: fn(&Self) -> &'a str = my_bar; 
} 

fn my_bar<'a>(a: &MyFoo<'a>) -> &'a str { 
    &a.x 
} 

En ce moment, je ne peux pas penser à la façon dont ce serait plus bénéfique qu'une méthode.