러스트 Rust, 라이프 타임이란?

라이프타임이란 무엇일까? 쉽게 얘기해서, 변수가 살아있는것을 지정 할 수 있는, 러스트의 안전장치이다.

자, 그렇다면 예시를 들어보자.

fn longer<'a>(s1: &'a str, s2: &'a str) &'a str {
    if(s1.len() >= s2) {
        s1
    } 
    else {
    	s2
    }
}

위 함수는, s1, s2 레퍼런스 리터럴 스트링(literal string)을 받아와서, 그것을 그대로 반환하는 함수이다.

이때, 우리는 s1과 s2의 레퍼런스 주소가, 만료된 것 인지 모르기 때문에, 이것은 완전히 안전하다 할 수 없다.

즉, 컴파일 타임때, 러스트 빌림 검사기(borrow)가 체크하게 우리가 만들어줘야 프로그래밍을 원활히 할 수 있다.

이때, 'a로 라이프타임을 모두 같이 해준다면, 최소 라이프타임 'a 만큼 ('a는 자동적으로, 모두가 살아있는 적절한 레퍼런스 라이프타임을 가진다) 살아있게, 컴파일러가 이 함수를 호출할때, 확인을 하고, 에러를 내준다.

주의할 점은, 절대로 라이프타임을 지정해준다고 하여서, 인자의 라이프타임(받아온 레퍼런스의 라이프타임)을 늘려주진 않는다.

그러므로, 우리는 컴파일 타임때 IDE나 Editor-plugin-이 포착하여 알림받을 수 있다.

헷갈리지 말라고 다른 예를 준비하였다.

예시 상황

만약에, 어떠한 String literal (&str) 배열을 받아왔을때, 우리는 그 값을 다른 변수에 할당하고 그것을 또 HashMap에 넣고, 리턴하고자 한다면, HashMap의 값 타입은 절대로 &str로 선택하면 안된다.

이유는, 받아온 인자의 라이프타임이 어떻든 간에(선언을 하던 말던, HashMap과 라이프타임을 일치시키던 말던) 받아온 인자는 그대로 해쉬맵에 저장하여 리턴하면 되지만, 따로 꺼내온 (for문을 이용해서든지..) &str은, 함수가 끝날때 무조건 사라지기 때문이다. 이것은 자명한 사실이고, 이 값을 HashMap에 넣고 싶다면, to_owned()나 to_string()을 이용하여 string::String으로 변환 후, HashMap에 저장하는 것이 옳다. string::String은 레퍼런스가 아닌, 값을 담은 벡터이다.

결론

라이프타임은, 사라져가는 레퍼런스에 대하여, 이것이 유효한 레퍼런스(포인터)인지 컴파일 타임때 프로그래머가 검사할 수 있도록하는 안전장치이자, 평소에는 굳이 쓸 필요 없는 (주로 값을 담은 class ex, string::String것을 반환할때) 것이다.